Empowering First Nations Language Owners to build custom games without the tech barriers
A game building tool for Language owners to build their own game experiences within the Languages Platform with minimal in-house support. The tool also speeds up the process for the in-house team and opens the door for game experiences to be build by less tech-proficient users.
My role
I was involved in designing the whole user experience of the game map builder. I also did some supported front-end development styling the app.
Outcomes
- Language Owners are now able to start their Language Learning Experiences without heavy assistance from internal teams. This is especially useful as staff capacity has since been reduced due to budget.
- Since the Dharawal pilot group, groups representing Awabakal, Paakantji and Murrinpatha languages have started building their own experiences.
- The process has also become much easier and more pleasant for in-house staff who can now build game experiences in just over 30% of the time it took using old methods.
- The technical struggles were now out of the way and users could focus on what was important – the content itself.
- Language Owners are now able to start building their Language Learning Experiences without heavy in-house support.
Experiencing the improvement personally
The first time I used the new tool, the improved experience caused a smile to spread across my face with the benefits apparent the as soon as I had a chance to add content for a client using the new tool. The time it took to add content was markedly reduced.
Designs
The process
Problem
The existing backend-driven workflow and risks of unrestricted access block Language Owners from building and customising their own game map experiences without relying on platform administrators. We need a more accessible interface that allows Language Owners to easily visualise, build, and publish their own game maps, speeding up the process and reducing staff burden while preserving cultural integrity.
Background
The Burraga Languages Platform has the potential to be used by at least 250 language owners to create Language Learning experiences that enrich efforts to preserve and proliferate the Languages of Aboriginal Australia and ultimately uphold Aboriginal identity into the future.
There are over 250 Aboriginal Languages in Australia which means that a language owner that wants to create a language learning game experience for their language would potentially have to wait while platform administrators create their experience to match their vision – and for any edits going forward.
It also presents a burden for the small internal team who have to contend with delays in content planning and submissions by Language Owners amidst under-resourcing and juggling of multiple projects. Once content is finally received, the platform admin faces a cumbersome process of uploading assets, and filling in language content all through a complicated backend. Can we make this easier?
Goals
To solve the problem, a senior stakeholder pushed for a self-service tool to reduce staff burden and accelerate delivery.
The goal:
- Speed up the process of building out the game map.
- Allow for Language Owners to build out their own game map experiences.
- Allow for less technically adept users to partake in the building experiences.
- Eliminate the risks of damage to other accounts through unrestricted backend access.
- Reduce burden on internal staff who, until now, were having to build these experiences.
Who?
We were designing this for:
- The Language Owner and their nominated team members – These users have some technical proficiency but are not able to use the backend CMS in order to create their learning experience. This is due to lack of access and level of expertise.
- The platform admin – The platform admin is an in-house member of the team. They have the skills to create the game experience using the backend CMS but this process is cumbersome and slow and prone to error.
The game building process would now be opened up to more of the team as the skill level bar had been lowered.
Constraints/Points to consider
- To maintain community trust only those with certain permissions can create content and content that is published must also be approved.
- Limited budget and time due to not being in the original scope.
- Limited availability of designers and developers (1 designer, 2 developers).
- Balance of Consistency and Customisation. We needed to provide an experience where Language Owners can tailor their game experience while also keeping within set parameters to maintain the overall product identity. For this we decided that the user would work with templates which they would fill in with their own content.
Research
looking at other interfaces
Looking at other builder interfaces, I noted what worked and what didn’t. The interfaces that possessed visual resemblance to their final product worked well as the user could get an idea of where their their placed content would appear.
Speaking to stakeholders
Stakeholders directly involved with client content reflected the need to have a better system for language owners as the process of developing the content for the client was becoming a time and resource burden.
Working with language owners
Having been through the process of working with the client to add content in ‘the old way’, I had gained experiential insight into issues that needed to be addressed. It was clear that language owners needed a fair amount of support and often didn’t know quite what they wanted. This is where providing ready-made templates would prove useful.
designing builder templates
I set about designing builder templates for each game that was already in the app, starting with very rough sketches. I often use these very rough sketches as a way to ‘think out loud’.
As I designed the templates, I shared them with the team to get their feedback. We built these out quickly and designs were refined as the working templates were tested in-house.
I also had to design interfaces for the user to build out their custom game map and create their game sequences.
Keeping the process moving
So that the developers would have a steady flow of work I had to think about the order in which to design all of the pieces. I started with the game templates and broke up the tasks per template so that each part could be developed separately and in manageable chunks.
I clarified details and answered questions for the developers as needed and aimed to include as much instruction as possible so that the process could run smoothly.
Challenges
As I was thinking about these templates, some felt more straight-forward than others. The match games, for example, were simpler to design workflows for but others felt more challenging.
The processes that were especially challenging to design interfaces for were:
Working out where collectables belonged within the game builder
Now that collectables were added to compensate for lack of side activities, there was now an issue in the builder tool concerning where the building out of the collectables would belong.
In a published game, a badge was displayed for each collection on the learning achievements screen to convey how many collectables were found on the game map was displayed to convey.
But like the side activities, these collectables would be placed along the peripheral game map path when there was no available side content.
There was a question over where one would create their collections and solving this proved to be a bit tricky.
Sing with me template
The original way to build out a sing with me activity was rather complicated, requiring the content creator to first add time codes to their audio with an audio program as well as create a JSON file with the start and stop times of each phrase.
The new sing with me builder needed to feature the ability to add time markers and also be intuitive to use – there should definitely not be a need to create any JSON files, nor use any third party software to add time codes.
Reflections
Because the game logic was already built out, in order that the development time was not wasted I decided that I needed to align the design around the established developmental framework. For example, consider existing required data and create inputs for those data.
Being a foundation, the budget and time was not there for a lot of research. I would have wanted to do more user testing and iteration but at this point the budget was running low and further refinement was not an option.
Where to?
If there was more time and budget I would have wanted to work on making the templates even more user friendly, making some visual refinements and including more instruction where needed, an instructional overlay or a help section.