Wild Things

A terrible storm has ravaged the Wildlands and it’s up to YOU to save the Wild Things! You are a magical caretaker, sent to help best friends Liam the Lion and Emma the Elephant as they try to rebuild their homes and revive their animal friends. Play challenging Match-3 puzzles, design and renovate the animal habitats, take care of cute critters, and uncover the mystery behind the storm as you embark on this exciting animal adventure!

Contents:

Here are some of the works that I did for Wild Things. This isn’t an exhaustive list of what I’ve done but some that I have lead and have taken ownership of:

Role:

Jam City | Mobile Game | UI/UX Designer | 2018-2020

• Started with designing a user flow for the game then moved on to design various UI assets and designing new experiences for users through main and meta features. I worked with the Engineering department to create prototypes of the features and as well as implementing them to the live build.
• To establish visual standards and guidelines for Wild Thing’s user interface, modals, and HUDs. Document each design thoroughly in Confluence, Give direction to 2D artists who will help finalize each element for the game. Work with technical designers to create visually appealing UI animation and effects for the game.

Process

Concept:

I work with the principal designer for a feature or an event to come up with solid ideas for what we’re working on. The principal designer usually works on the specs and mechanics and I work on the UX specs for the event. Any piece of paper will do for me. We also assess the art and engineering requests that we need for a particular event or feature. The product manager will then weigh in and the producer will create a time frame after all necessary involved parties sign off the approval.

My concept phase involves a lot of sketches, write ups and wires on different media. If an idea comes at an unexpected time (bed time), whatever I have on hand will be my choice of tool; usually Notes on my phone, but I tend to use a notebook or a piece of paper to scribble and write my ideas.

Wireframing:

Once I have a super-rough concept, I try to create the wireframe and the flow for what I am working on. I usually show my ideas to the designer on paper, but for the process’ sake, it goes in to Confluence or Google Docs. This process is for some stakeholders to understand what we’re working on and to get their input and feedback to some of our decisions.

Mock Ups:

After getting some head nods and yeses on the wireframes, I start on working on some mockups. I tend to lean on to making high quality ones if there are already some art assets that are approved. Some stakeholders prefer to see high quality mock ups as well. I usually make these mock ups through Unity so I can create the prefabs already for creating the prototype. Doing mock ups in Unity saves us a more time than doing it in photoshop and replicating in Unity. I’d rather have the visual specs determined before hand so after prototyping, we can just polish.

Prototyping:

Our engineer will then proceed to create the prototype based on the principal designer’s specs and the prefabs that I’ve created. I make sure that the engineer has what he needs before he proceeds with what he/she needs to do. We’ve worked out a process that all of our prototypes should be within our game build, and on an internal distribution, and hidden under a debug cheat or menu.

Testing/Review/Iteration:

Testing on Device is something that I told my peers that I want to do for our features. For visual testing, a jpg or png on correct resolution can work but Unity has some specific calculations on how it displays an image in game. Prototyping on build or device allows us to troubleshoot and see what we missed. It could be a wrong compression setting, or an image is placed wrong, or etc.

Our stakeholders will then review the build and the feature, give their feedback and we’ll address it as soon as we get an official ticket for it. Once all the necessary feedback is addressed, we’ll introduce it to the build then will be checked by leads before including it in our release candidate.

Approval:

Once all the feedback and changes are applied and there are no more changes needed, the feature will be fully implemented and will be awaiting for the final review of the release candidate before submitting to the AppStore.