About



The initial idea for this project came after noticing a clear lack of the classic zoo management style of games often seen on computers. In fact, there is a distinct lack of management style games in general on mobile platforms, many of those offered are produced by a singular developer, leaving a strong opportunity to slide into this area.





The Team
Tools Used
My Role
Javier Guzman (Solo)
Figma
User Research
OptimalWorkshop
UX/UI Design
Adobe Photoshop
Wireframing
Prototyping

Content

01
Initial Interviews
02
Personas
03
Competitive Analysis
04
Card Sort & Information Architecture
05
Initial Low-Fidelity Wireframes
06
Tree Test
07
User Flows
08
Finalized Information Architecture
09
Wireframe Iteration & Initial Prototype
10
Accessibility Evaluation
11
Afterthoughts

Initial Interviews

Player Insight
Initial Interviews played a large role in the understanding of the project's goals and direction. These interviews provided the project with player habits, feature preferences and expectations, initial opinions on the project, and an understanding of what Alignimals would be competing with.

To start the project, 16 participants were gathered and screened, moving forward only with those who had played mobile games within the last month, and interviews were done to better understand the playing habits of mobile gamers. Some additional questions were also asked in order to gauge interest in the style of game the project was aiming to create as well as to understand what features players might expect and prefer in such a game. Participants were asked the following questions, some open ended and others multiple choice where appropriate:
1) What mobile games have you played recently?

2) Where and when do you usually play?

3) How long do you play in a single sitting?

4) Which most accurately describes how recently you played a mobile game?

5) What, if anything, do you like about mobile games?

6) What if anything, do you NOT like about mobile games?

7) Do you have a favorite mobile game? What do you like about it? What do you not like about it?

8) How do you feel about a game focused around collecting animals and building a zoo with them? Not Very Interested to Very Interested (Likert Scale)

9) Are you familiar with Tycoon Simulation type games? (e.g. Zoo Tycoon, Rollercoaster Tycoon)

10) In an animal based Tycoon game, how important are the following features to you (Very Important to Very Unimportant, Likert Scale)

An affinity diagram was then created to visualize the different information collected from the interview process, allowing for an easier exploration of user sentiments.

Affinity Diagram

Personas
The initial interviews gave the project a good starting point into understanding the users that might interact without Alignimals. Three personas, representing three distinct types of users, were thus created, influenced by the affinity diagram in order to better cement and personify the different types of users, their use cases, issues, and desires. The three categories of users I ended up on were: casual players, dedicated collectors, and competitive players.

Competitive Analysis
A competitive analysis was also done in order to gain a better understanding of the games that the participants in the initial interview mentioned by name. Doing this allowed even further visualization of the information observed during the affinity diagram. The chart allowed an at-a-glance understanding of the types of content the interview participants interacted with in other similar games. This information acted as a great starting point for the type of content Alignimals might want to incorporate into its experience, in essence, taking the best parts of other popular games.

Research & Frameworks

Card Sort & Initial Information Architecture
A remote open card sort was conducted with 16 initial participants using OptimalWorkshop. The goal of this card sort was to start collecting information for the creation of the initial information architecture as well as better understand the potential terminology I could use for menus and buttons. Users were given cards describing various features of the game decided through the competitive analysis and initial interviews. Below is a dendrogram created using the information collected from this card sort displaying the best merge methods for the content which was planned to be included.

With the information on what content users expected, where they expected it, and what content they tended to group together, an initial information architecture could now be created to plan out the structure of the app, the connections within it, and titles for screens. This initial work was made with the understanding that it was not final, not perfect, and expected to be iterated on. However, the benefits of this work came to fruition during the created of the initial wireframes and for the tree test as it allowed for a solid foundational structure to test upon.

Initial Low-Fidelity Wireframes
Using all the information collected thus far, from the interviews, to the information architecture molded by the card sort, initial low-fidelity wireframes were created through multiple iterations to visualize the initial design and navigation thus far. The image below was the low-fidelity wireframes that were ended on, they kept the structure simple and the navigation seemed easiest for users to move through. Inspiration was taken from various other mobile games mentioned in the initial interviews, most notably the UI organization and placement.

Tree Test
As the first step of iterating on the initial wireframes a tree test was conducted in order to improve the navigation of the design and evaluate the initial site structure developed previously, seen in the initial information architecture. One of the main findings from the Tree Test was the confusion centered around where certain content was expected to be in the application. While participants were successful in navigating to the sections where they would hire new zoo staff and to the game play, they were not successful in finding where they would navigate to in order to find animals they do not yet possess (“Your Collection”). 70% of users failed to navigate to the “Your Collection” section, while the other 30% of participants were only able to arrive at the correct section indirectly (Figure 1). No participants' first click led them to the correct section, the “Exploration” page under a “Your Collection” button. In contrast when participants were asked how they would navigate to get to the puzzle game play or where to hire new zoo staff, the success rate was 90% and 100% respectively (Figures 2 & 3)
As a result of these findings, the collection section was moved into the “Animal Info” page in the reworked information architecture and the Exploration section was remade to only house the path towards the game play. This decision allowed us to line up our navigation with user expectations which would prevent any confusion or incorrect actions when navigating to important, commonly used features of the game.

User Flows

The prior tree test results which highlighted that 90% of the participants were able to correctly navigate to the game play section accentuate this user flow (60% arrived directly), highlighting the directness and ease of navigation for users whom only require two clicks after their initial choice of the exploration section. For users who did not take the correct path, the 10% observed in the tree test, they are given amble opportunities to navigate back after every choice they make allowing them to correct their mistakes easily with one simple click returning them all the way back to the home page from whatever section they're currently in. Another important note, given that 30% of the tree test participants did not arrive at the goal directly (meaning they would have an opportunity to get lost in other sections) it was important to make the choices distinct and easy to understand to prevent incorrect choices. As such, the names attributed to the navigation buttons on the home page were reworded to be more specific in their meaning. Instead of "Animal Exploration" and "Animal Info", of which the latter was the correct choice to get to the game play, they were now named "Exploration" and "Animals". This change would still keep the main meanings of the previous options, which would prevent the tree test results from being invalidated completely, but now instead made a clear distinction between the two to prevent confusion and incorrect choices.
This flow was much larger than the previous, mainly because this task required users to delve deeper into the application. In ideal circumstances, users would only need two three clicks to get to the hiring screen. However, because of the need to delve deeper, the user encounters more screens with various options to get lost in when compared to the previous user flow. Thus, it was important to highlight the various methods users were given to correct their mistakes, as well as how navigation pages were kept to a minimum as to not require users to click the back button multiple times to return to where they need to be. Unlike with the previous user flow for the game play section, participants had a much higher success rate at navigating to this end goal (100% of the participants correctly arrived at section to hire new staff, 10% indirectly), thus the "Management" label was kept as there was no indication that changing it would lead to any benefits or lower navigation errors.

One final important thing to note is how the “Failure” conditions end up being relatively deep into both user flows because of how many opportunities users are given to return towards the correct path.

Finalized Information Architecture
The reworked information architecture incorporated various changes from the card sort and tree test as well as smaller changes such as condensing section names such as renaming “Animal Exploration” to just “Exploration”. Additionally, the information architecture diagram was expanded upon to include a more in-depth look into deeper page navigation and their accompanying features. Some other changes to the information architecture included a Shop section, and the aforementioned “Your Collection” section into the “Animal Info” section. Blue highlights denote an interaction leading into a deeper page, while a red highlight denotes an interaction that leads the user back into previous sections either through a direct “back” button or the completion of a task..

Iteration and Presentation

Wireframe Iteration
As mentioned in previous sections, various changes were made and areas expanded upon or moved which has led to the need for reworking the navigation UI to reflect the new direction taken since the initial wireframes. For example, instead of the four buttons on the main screen present in the initial wireframes, now the UI has an additional smaller “Options” button and the larger fourth button is now used to lead to the shop which was not present in the initial wireframes. Additionally the reworked wireframes now include pages deeper in the navigation which would now assist in the creation of an initial prototype.

Initial Prototype

Design System

Accessibility Evaluation

Text Hierarchy
Good text hierarchy practices were followed throughout the creation of the initial prototype. Headings are consistent in size and are always the largest text on a screen. Important text information is larger in size than descriptor text for elements (14px). As a result, the screen and content on the screen is easily legible, content sections are easily discernible and are oftentimes separated by not only differing text sizing, but also borders and backgrounds.

Text Size


Text sizing is consistent between similar use cases. Screen Headings are the largest with a near 60px size (Exact sizing is not available due to the custom font used), section headings on pages are then the second largest size (near 46px), the last consistent text size used was for miscellaneous text (14px). This 14px text was used for every piece of text apart from the headings, section headings, and button text. Those buttons have a variety of text sizing according to the button size, thus aren't consistent in size. They range from 14px to around 30px.

Contrast
On initial inspection, multiple elements did not pass the WCAG AA contrast guidelines. There was not enough contrast between the white text and slightly dark backgrounds it was placed on with many initially having contrast ratios as low as 2.5:1. After a quick iteration, the backgrounds for the non-adhering text were darkened slightly and a dark outline was given to smaller text to increase the contrast ratio to at least a 4.5:1 ratio making them WCAG AA contrast compliant at a minimum.

Moving Content
The prototype does include moving components such as the slight bouncing of the various animal sprites, however none of the content contains flashing or blinking lights so there are no concerns over photosensitivity and seizures at the moment or in the forseeable future. Despite the low risk of any major issues, an option is available under the settings menu to turn off all cosmetic motion such as the animal idle animations.

Color Blindness
In order to be inclusive to those with different types of color blindness the prototype was designed to not place importance on the color of various required interface interactions. For example, buttons are all labeled and their design is kept consistent throughout the application. Thus, even without any color, buttons and interactable elements are visually distinct. Other elements (such as the bubbles in the game play screen) have unique visual elements to visually separate them without the use of color as well (each bubble uses a different animal icon).

Afterthoughts

A Short Retrospective On The Project
As with any type of work one does, there is a lot I'm unhappy about, and a lot I believe I was blinded about during the design process. For starters I will say that I'm content with the research done for this project, a lot of my gripes rest not on that, but on the design side of the work.

If given enough time and resources I would have used different visual elements for this project. However, given the time I had as well as not being a pixel artist, I was limited to what I could find for free from various talented artists. As a result, I believe the prototype does not have a 100% cohesive look to it precisely because it's a hodgepodge of work from various artists including myself.

Expanding on that previous point, I didn't like how a lot of the buttons and framings turned out. This was one aspect I believe I was blinded about during the design process. I believe I was too invested in keeping a cohesive “pixel” theme and I ended up settling for subpar work in some sections just because I thought they fit thematically at the time. If I was to work on this project further I would first attempt to collect more outside opinions then potentially rework some of the navigation UI visuals.

Keeping up with what I'd do if I continued working on the project, usability testing would be what I pursued next using the prototype. Tasks would ideally partially focus on aspects of the project that were part of previous research, such as the navigation, making sure the changes made using the previous data were successful. Another task would ideally ask participants to go through the zoo building process, testing the other important mechanic of the game.

Finally, as to not be so somber, I was content with the information architecture and overall user experience in regards to navigation. Thankfully because of this, I believe that even if I went back and reworked some of the UI as I mentioned, as a whole it wouldn't take too much time as the underlying work is something I feel is sound.