A UI/UX case study focused on redesigning the SSS in SSBU complete with user research, usability testing, and a testable proof-of-concept prototype




User Research & Testing, UI & UX Design, Programming & Implementation

3 months (12-14 weeks)

Figma, InVision, Unity & Visual Studio (C#)


This project is not officially affiliated with the Super Smash Bros. franchise. This is merely a personal project and I did not work on any official product for the series.




Finding & identifying frustration.

I play a lot of Super Smash Bros, which naturally means that I play a lot of the newest installment in the series: Ultimate. The stage selection screen has always stood out to me like a sore thumb. With over 100 stages all sharing only a portion of the screen's real estate, finding a stage to play on is a tedious and frustrating task.

Testing for this same frustration with users.

Now, at this point my aforementioned opinion on the stage selection screen was to be taken with a grain of salt. I'm only one user, and my opinion - while it may be valid - may not be shared by many others. To be able to gauge how much of an issue this frustration truly was, I created a survey using Google Sheets and posted it on multiple outlets online. My family and friends also played a part in this by helping post it around the circles that they run in, allowing me to get more perspectives outside of people that play and/or develop games.

With over 160 testers participating in this survey, I got a lot of good results and a lot of good insight. The first half of the survey had testers actually using a screenshot of the stage selection screen from the game to try finding a stage, where they were then asked questions about their experience afterwards.


 The most important takeaway from the survey comes from two different questions (seen in the graphs below). First, I asked testers whether or not they thought finding their stage was difficult (graph #1); the responses were split almost exactly 50/50. While this may not initially seem alarming, I think that if 50% of the playerbase thinks one of the main screens used in the game is difficult to use, there is cause for concern. The other question asked how frustrated testers felt with this screen (graph #2), where the results seem to show that testers didn't find it frustrating at all. I then thought to cross over these two graphs (graph #3) into to be able to identify trends with testers from the two groups in the first question answered the second question. As you can see, the two groups have extremely different different results in their graphs. Those that thought the screen wasn't difficult to use obviously leaned towards the lesser side of frustration, but those that found the task difficult had much more spread out responses with their level of frustration, with a spike towards the middle. This just reaffirms the fact there there is an issue with the current design of the stage selection screen.


Was it difficult to find the stage you chose in the stage selection screen?

So now it has been established that users are having a significant amount of difficulty with the stage selection screen as suspected. What exactly is it about the screen that causes this frustration? Well, I also asked testers to identify what specifically was bothersome about the screen in two different questions: one asking them to mark any frustration they had, and one to identify which one of those frustrations was the biggest issue. Because of the amount of possible unique answers given, I had to compile these frustrations into categories.

Q: What was frustrating about finding the stage? Check all that apply.

  • Icons are too small - 106 answers (63.5%)

  • Visually overstimulating - 77 answers (46.1%)

  • No sense of organization - 75 answers (44.9%)

  • Some stages are too similar - 71 answers (42.5%)

  • *Was viewing the form on mobile - 4 answers (2.4%)

  • *None; I have the screen memorized - 3 answers (1.8%)

  • *Didn't have any issue - 8 answers (4.8%)

Q: Which of those choices do you think was the most frustrating?

  • Icons are too small - 60 answers (35.9%%)

  • No sense of organization - 50 answers (29.9%)

  • Visually overstimulating - 33 answers (19.8%)

  • Some stages are too similar - 18 answers (10.8%)

  • *None; I have the screen memorized - 2 answers (1.2%)

  • *Didn't have any issue - 4 answers (2.4%)

* These responses were not included by me in the form, but were filled in by testers themselves.

As seen in the results above, the main issue with the screen is that the icons are too small to be able to discern which stage is which (although all of the other issues I outlined seem to be problems as well, just not nearly as drastic as the size of the icons). This is due to how SSBU is displaying every single stage on the screen at once, and with over 100 stages, each stage can only take up so much space. The reason this was done is most likely to have every single stage be as physically accessible as possible, with each stage requiring only 1 click to access, but this is at the cost of every single stage being less visually accessible.




Using questions from research to find possible personas.

On top of the questions detailed in the section above, I also asked questions about the tester's demographic and their familiarity with not only Super Smash Bros. Ultimate but the SSB franchise as a whole. This was to find trends in my data among users from different groups and, as you an imagine, to develop personas to aid and guide my development and decision making in the future.

The three personas detailed below cover the bulk of the testers seen from the preliminary test that can be considered a part of SSBU's audience. The first persona (Daniel "Woodchip" Trajano) is a reflection of the more competitive side of players - those that go to tournaments, try to improve at the game on a regular basis, and have a more competitive mindset. The second persona (Abigail Clinton) represents what seems to be the largest portion of the playerbase - users that enjoy the game, but don't play it on a very frequent basis. These players tend to play the game with their friends and have varying levels of competition, usually sitting somewhere in between the two extremes. The last persona (Jeffery Hofstede) is the smallest group of users, but is still worth noting (I wasn't even fully aware of this as a player group until I did the survey analysis) - these players really don't care for the game that much at all, but only play because of the people around them. Commonly seen in this group are family members such as parents who's children want to play the game with them.



Concepting a new design to remedy the identified problems.

With the data acquired from the project's preliminary testing, the biggest reason for why people get frustrated or have difficulty with the stage selection screen seen in SSBU is that the icons for the stages are too small (with it being the only questioned issue that had over 50% agreement with testers, it is the one I decided to focus on). With wireframing, I wanted to address this issue as directly as possible while also fixing up other issues as I saw fit.

To give a better point of reference, I'll show off a picture of the current stage select screen in SSBU along with some points of the main changes I made with reasoning as to why.

  1. Increasing the size of the stage icons
    This solution seems simple enough, and while it is, it came with some other issues and things that needed to be addressed. As mentioned in previous sections, my guess as to why the screen was designed as such is to both allow players to pick a stage with only 1 click and to be able to showcase every stage at the same time in parallel with the underlying theme of Super Smash Bros. being a celebration of video games. The latter is especially true in Ultimate since it's trying to play up the fact that (as seen in the game's roster reveal) "EVERYONE IS HERE!". While the sentiment of this design means well, it has too many glaring issues to really be worth using. Now, the issue with having bigger icons is having less screen space, so...

  2. Adding in organized tabs/categories
    Tabs were added to be able to separate all stages to allow for bigger icons to take up the screen while still showcasing every stage the game has to offer. This does add in another series of clicks to have players find the stages that they want, but for this very reason I chose to add in a "Favorites" tab (better shown off in the actual prototype of the redesign). With this addition, players have no need for memorizing where their stages of choice are and can easily edit which stages are most accessible.

  3. Using up as much screen-space as possible
    One issue that I didn't really test for since it didn't run extremely parallel with what I was trying to test is that the original screen does not use its screen-space as best as it can. The top left and bottom left corners are both empty due to the preview of the selected stage being between them, leading to wasted space that could be used to remedy issues or bolster solutions. In my wireframe, I chose to maximize screenspace by having the background be the selected stage preview, allowing for users to see their selected stage on a larger scale and to not have any wasted space on the screen.


As you can see, all of the stage icons have been moved to the bottom of the screen into two rows, with the tabs sitting right above them. Because I wanted the wireframe to be as neutral as possible while still conveying the idea as best as possible, I used single letters as stand-ins or what would be icons in the tabs. Additionally, I did not want to include actual pictures of the stages yet since this was only a low-fidelity wireframe meant only to convey the actual layout and the base idea/concept. Because of this, I used words as replacements for the stage icons, with each one starting with the letter of whatever tab they were in, in this case the letter 'A'. The background, while it does not change in the wireframe, would display the currently selected stage on top of the name banner coming in from the right when a stage is selected. There's also one screen worth talking about; when a tab has a small amount of stages, the stage icons change from two rows to one row, but they increase in size as to keep the actual allotted size of the panel at the bottom consistent. I also included things like a panel for music selection and stage info, but focus shifted away from these two as they were not the focus of the project.



Testing wireframes and iterating based on feedback.

With the first set of wireframes in place, I exported them from Figma and moved them over into InDesign for some usability testing. This was to actually get feedback on the flow of screens without having to wait an exceptional amount of time for a usable prototype; low fidelity was the name of the game to be able to determine if these designs had any major holes or issues that needed to be addressed. The way this was done was through a series of tasks given to the user, where they would all stem from the same landing screen. By clicking on certain areas of the wireframes, they would be led to other versions of the wireframe, simulating the real experience on a very low-level visually.

With a total of 3 in-person tests, here is what I gathered from the first test session:

  1. The screen layout is straightforward and easy to understand.
    This was a relief to see, and definitely a step in the right direction from the original screen's design. During the testing, there was hardly any moments where testers didn't know what to do immediately - there were a few moments where they would pause briefly, but this was just to process the change in the screen's layout.

  2. The main source of confusion came from the phrasing of certain buttons.
    In this test, I was not only testing the stage icons and their placement and organization, but also every single other button like the button to change the stage's form or even the button to choose the music of the stage. Having said this, there was only a little bit of confusion in terms of the stage icons being represented with words as opposed to pictures; after brief explanation of why they were made like so, testers understood. The biggest source of confusion was the aforementioned button to change the stage's form. One tester said that the button made sense from the point of view of an experienced player, but not from that of a new player.

  3. There was a lot of inquiry about what the planned method of tab organization was.
    With the way of representing the tabs and the stage icons being so abstract, every single tester wondered what I planned to do for the method of organization. There are several possible ways to organize the stages: by size, alphabetically, or by franchise to name a few. This level of inquiry from testers and all of their differing opinions on the matter shows that I needed to do more research into what the best organization method would be (ideally one that makes sense to the largest amount of users).

Foregoing more testing to prevent potential design issues.

After this first set of usability tests, I got started on actual implementation of the design into Unity. While working, I began to see some issues with the wireframes that did not come up in testing because I was never even aware of these being issues, meaning I didn't ask questions or have the testers forego tasks that were related to these issues. These problems are both related to screen-space, specifically with the number of rows that tabs have for the stage icons. Below is a wireframe of a screen that best shows off the problem.

With my original design, there were two main issues I identified:

  1. Changing the size of the stage icons causes inconsistent design.
    The main issue I saw was the difference in the size of the stage icons when transitioning between a tab that has 1 row of stages versus 2 rows of stages; the former has icons that are almost quadruple the size of the latter. While one might think that bigger icons are better since it addresses the original problem identified in testing, it also creates an inconsistency in the usability of the design.

  2. Having two rows of stage icons causes the background to be very squished.
    Another related issue with the number of rows was that having two rows squished down the amount of screen space available for the background to preview the stage that's being selected, making it hard to distinguish what that stage really is.


To remedy these issues, I redesigned the screen like the images in the slideshow above. In order to keep a consistent size for the stage icons while also giving more room for the background image to show what stage is selected, I reduced the amount of rows to just 1. I also widened up the areas the to the left and right of the stage icons section to give more breathing room for the arrows that pop up if a tab has more stages that the screen space will allow; this allows the arrows to pop out more at users and makes them easier to identify.

And so, I went through another round of usability testing, but this time with the updated wireframes. I worried that the changes I made could cause more harm than they would help, so testing again would ensure that this was the right path to go on. I made sure to test this on 3 different users to make sure there was no previous exposure to the project that could influence their answers and decision making. In these tests, I discovered:

  1. Moving to the one-row limitation has no identifiable drawback.
    Not a single tester seemed to have difficulty with going through the tasks outlined to them in this design. If anything, having less icons on screen at any given time made things easier for them!

  2. Finding the arrows to move to other pages inside of tabs was not immediately understood.
    Some testers did take a second to find and identify the arrows needed to navigate to other pages of the tabs, but this only seemed like a minor hiccup and not a huge issue. Even still, this just means that the arrows need to be more pronounced than I had them in the wireframe.



Having users determine the best method of organization.

Up until this point, it was only decided that the stages were going to be organized into tabs, but the actual method of organization was unclear. In the current screen, the stage icons are ordered chronologically by when they were added to Smash, with the more recent stages being towards the bottom. This didn't help at all with making the screen understandable; in fact, 45% of testers from my preliminary test felt as if there was no method of organization, with 30% of testers thinking that was the main issue with the screen. Part of this, of course, is that there's no indication in the screen itself of how its being organized, where as my redesign has visuals on each tab to give it that point of reference. I had thought the best way to change this was to organize the stages by franchise, but from talking with my friends before doing any sort of card sort testing, I began to see that many people had different ideas as to what the best method of organization is. Because of this, I prioritized card sort testing in order to come up with a way to organize the stages that would make sense for the most people and be as transparent as possible.

The way I went about doing the card sort tests was by printing out two versions of every single stage in SSBU - one with just an image of the stage, and one with both an image and the stage's name. I figured because of how long it would take testers to sort out all 108 stages already, finding willing testers was going to be difficult enough, so I had each tester I did find go through 2 card sorts with both versions of the cards. I thought that having access to the stage's name on top of a picture of it might give them more information on what the stage is and would give them other ideas on how to organize the stages.


Q1: How often do you play SSBU?

"Very rarely."

Q2: How would you describe your skill level in SSBU?

"Very bad."


Sorted by Color Scheme

  • Sunny blue skies

  • Darker, moody

  • Cutesy, petite

  • Tan, blue

  • Detailed, not colored

  • Icy, cold

  • Balance of dark and light

  • Video game, retro


Sorted by Theme

  • Mario + Sonic

  • Retro, arcade, nostalgia

  • Drab, detailed structures

  • Fluffy fantasy

  • Pokemon

  • Grassy, intricate, fancy

  • Fire, desert, dusk

  • Wii and Wii adjacent

  • Cities + vehicles

  • Jungle

  • Cute

  • Space, dark


Q1: How often do you play SSBU?

"Twice a month."

Q2: How would you describe your skill level in SSBU?

"Casually experienced."


Sorted by Physical Layout

  • Floating island (no hazards)

  • Floating island (with hazards)

  • Flat arena (no hazards)

  • Flat arena (with hazards)

  • Other

  • Unsure


Sorted Alphabetically**


Q1: How often do you play SSBU?

"Twice a week."

Q2: How would you describe your skill level in SSBU?

"Medium skill level."


Sorted by Franchise

  • Mario

  • Luigi

  • Pokemon

  • Kirby

  • Kid Icarus

  • F-Zero

  • Yoshi

  • Wario

  • Donkey Kong

  • Metroid

  • Legend of Zelda

  • Fire Emblem

  • Super Smash Bros.

  • Animal Crossing

  • Mother

  • Star Fox

  • Sonic

  • Etc/Miscellaneous


Sorted by Competitive Viability

  • Is or is close to competitive viability

  • Can never be competitively viable


Q1: How often do you play SSBU?

"SSBU? Only once. SSBB? Once a week."

Q2: How would you describe your skill level in SSBU?

"From 1-10, about a 6.5."


Sorted by Stage Layout & Interaction

  • Single Platform

    • Changing

    • Stationary

    • Moving background

    • Flat stage*

  • Ways to Die

    • Camera moving​*

    • Really big stages

    • Easy to die

    • Avoid cars

    • Die on the sides

    • Unclassifiable

  • Multiple Platforms

    • Moving​

    • One base + more

    • Multi-dimension

    • Many floors/stacked

    • Irregular platforms


Sorted by Franchise

  • Pokemon

  • Legend of Zelda

  • Sonic

  • Kirby

  • Metal Gear Solid

  • Nintendo

  • Yoshi

  • Mario+

  • Game & Watch

  • Animal Crossing

  • Final Fantasy

  • Xenoblade

  • Retro/8-bit

  • Fatal Fury

  • Metroid

  • Ice Climbers

  • Kid Icarus

  • Bayonetta

  • Star Fox

  • Smash

  • Jungle/Donkey Kong

  • Pikmin

  • Persona

  • Games I know but can't classify

  • No clue 


Q1: How often do you play SSBU?

"Once a week or two weeks."

Q2: How would you describe your skill level in SSBU?



Sorted by Franchise/Company

  • Metroid

  • Misc. Non-Nintendo

  • Fire Emblem

  • F-Zero

  • Pokemon

  • Animal Crossing

  • Smash

  • Misc. Nintendo

  • Star Fox

  • Big Hits of Nintendo

  • Mother

  • Wii/Mii

  • Legend of Zelda

  • Kirby


Sorted by Personal Opinion

  • S tier

  • A tier

  • C tier

  • D tier

  • F tier

  • Haven't played them

  • F- tier/garbage


Q1: How often do you play SSBU?

"Only thrice."

Q2: How would you describe your skill level in SSBU?

"Not good."


Sorted by Hazards

  • Has hazards

  • Does not have hazards


Sorted by Platforms

  • Has auto-changing platforms*

  • Does not have auto-changing platforms*

* Unfortunately, the photos of these card sort groups were lost

** Since this sort was alphabetical, no pictures were taken since the categories are fairly self-explanatory

From these card sort tests, I was able to establish two main takeaways:

  1. The most "neutral" method of organization is by franchise.
    Out of the 6 testers that participated in these card sorts, 3 of them chose to organize the stages by franchise. There is no other non-opinionated method of organization that shared the same number of testers, meaning that it is the one that the most testers understood. Because of this, I chose to organize the tabs in my redesign by franchise! This also contributes to how Smash is a celebration of multiple franchises coming together to interact by fighting it out; sorting the stages by which games they are from just feels right for Smash. Now, there still is the concern about users that don't know the franchise well or even at all. I think any method of organization would leave some people clueless, and this one seems to be the smallest offender of that. Additionally, because each franchise has a recognized logo/icon associated with it (which will be used on the tabs to indicate which tab is which), I predict that over time, testers will be able to familiarize themselves with which franchise corresponds to which logo/icon far better than any other visual for any other method of organization.

  2. There is an infinite number of biased ways to organize stages, and none of them are "incorrect".
    What this means is that there are so many different ways that users want to organize stages. Because of this, I think adding in a tab for players to "favorite" stages makes sense, because then they get to customize one tab to their own liking.  They can use this for stages they enjoy, think are competitively viable, or whatever they want. With the amount of stages in SSBU, adding in a Favorites section seems like a win-win-win solution no matter what other decisions are made in the redesign.



Implementation of my design from the ground up.

In order to get the most valuable feedback possible from testing, I set out to create a interactive prototype of my redesign in Unity. With my experience in not only design but also programming and basic art & animation creation and implementation, I knew I could create a high-fidelity prototype that conveys my vision of the design well while also being useful to gather more feedback from testing.

The first thing I did was set up the layout in Unity; the Grid Layout Group component for UI elements came in handy for this, since it meant I didn't have to worry about lining things up myself. After that, I created a ScriptableObject called StageData, which stores information for a stage's name, franchise of origin, and thumbnail icon. I set up two main scripts that would do almost all of the the communication to dictate what happens in the prototype: the Cursor Script and the Tab Manager. The Cursor Script was in charge of moving the cursor around, visual interactions with other elements, and calling functions from the Tab Manager upon input from the player. Whenever the cursor hovers over a stage, it takes in the information from its StageData and uses it to change the background and title panel correctly. The Tab Manager is in charge of updating the screen after player input is taken in with regards to, well, tabs! Every action is segmented into different functions, with things like determining which stages to load when switching to a new tab and another function to actually display all of those stages on the screen. Now, I need to give credit where credit is due: massive thank you to Mix and Jam for their Smash Bros. Selection Screen recreation, upon which a lot of the movement and raycasting my cursor borrows from.

The GIF above shows the beginnings of the layout, cursor movement, and changing background. One interesting thing not shown off in the GIF is how I'm telling Unity to put all those stages on the screen. Upon selecting a tab, the name of that tab (which in most cases is the franchise of the stages within it) is thrown into the TabManager, which then reads the resources folder of the project to find a folder with a matching name, which then has all of the relevant stages inside of it. Each of those stages is a StageData file, which when read by the TabManager, turns it into a copy of a StageButton prefab with the respective data from the Stage Data. These StageButtons are then instantiated into the Grid Layout Group, where they then organize themselves nicely!

At this point, I got tab switching working properly! By pressing Q and E on the keyboard, players can move to an adjacent tab from their current one, and using the code mentioned in the paragraph above, the TabManager passes in the name of the new selected tab and loads all of the stages within that tab instantly. You'll also notice that the tabs have a nice little animation to show they are selected, and additionally I changed the look of the stage's name panel. I was getting tired of having it be a solid color (the old version was by no means final, but I had previously intended for it to be a more stylized opaque banner) since it covered up a part of the stage's picture. By having the banner be a transparent gradient, it still shows off well as a background while still allowing the player to see as much of the stage as possible. Inside the panel, there's also an icon for the franchise of the currently hovered stage which changes based on the StageData from the StageButton the cursor is currently on top of.

Here is where the most notable changes happened. As you can likely tell, the bottom panel for the StageButtons no longer holds 2 rows of stages and instead only holds 1 row of up to ten stages. I began to idenitfy an issue where the StageButtons were taking up too much of the screen space, leaving the stage preview in the background a rather squished amount of space. To free up more room for the background to breathe, I knew I would have to cut down the rows to just 1, and I ended up performing more usability testing to ensure that there would be no issues with this change. From testing I saw there were no real issues at all, so I implemented this change and it helped out the issue I identified quite a lot! The only "issue" that came up was that some tabs have more than just 10 stages, so 1 row wouldn't have enough space. This was fixed with the addition of arrows leading to more pages within those tabs, allowing for a technically infinite number of stages inside of tabs. Asides from this, you can now see that the cursor now has actual icons and the ability to switch between them when certain conditions are met (thank you to Arturo Enriquez for providing PNGs of the actual cursor sprite from SSBU!). And finally, I added some feedback to the background to show players what tab they are currently on more clearly than the small tab icons. It also comes with the actual name of the tab, allowing unknowing players to start making connection between the icons and what they mean outside of just this menu's organization.

And here's the final prototype! The main addition in this version was the favorites tab being fully functional, allowing players to favorite currently hovered stages by pressing F on their keyboard. A little animation plays towards the left of the screen when a stage is favorites, and when players hover back over that stage, the same popup appears to ensure they know it's one of their favorites. The favorites tab dynamically changes as the player adds and removes stages to it, allowing them to add as many or as little stages as they want to the tab while having the aforementioned pages adapt accordingly. In accordance with traditional Smash Bros stage selection design, I also made it so players can select a tab not only through Q and E to move to an adjacent one but also by moving the cursor directly on top of it to select it! The reason for this is because stages are selected with the cursor, so tabs should also be able to be selected like so for a more cohesive design and experience. Users can also actually select a stage now, giving them a fast animation where the background quickly zooms and the title banner expands, along with all other non-selected stages dimming out to drive the player's focus onto the stage they selected. I also decreased the size off the franchise indicator in the background since it felt too cluttered and increase the contrast to make it pop out a bit more to the user's eyes.



Testing the prototype as a high-fidelity proof of concept.

With almost all of the functionality for the core of the redesign I had set out to do in place, it was time to test it all out to see how it compares to the real screen. Now, before we look at the actual data, I want to make some things clear: the preliminary test I did had over 160 testers, but this test only had 38 total responses (this is most likely due to the inconvenience of testers needing to actually download the prototype's build). Additionally, I posted this in as many possible outlets as I could to get as much attention and as many unique points of view as possible, but the test got the most attention from people that actually play SSBU. Over 84% of the testers have played SSBU before this test, so be sure to take that into account when looking at the feedback. Additionally, this test was all done online and depending entirely on self-testing and self-reporting. Because of the COVID-19 pandemic, I was unable to actually get any in-person testing done for this prototype.

With all that said and done, let me talk about how the test was organized and formatted! After some initial questions to determine the player's familiarity with the Smash Bros. franchise, I presented them with an image of the stage selection screen from the game and asked them to find three stages. After they either found all three stages or got sick of it and gave up, they then answered some questions about that experience.


Have you found all three provided stages in the original screen?

From this data, it's clear that the issues seen from preliminary testing are still present with this group of testers. By asking questions 1.1 and 1.2, I got to see how successful players were in finding the stages and whether or not they had any prior influence that would affect the test. The results make me believe that having prior exposure to the screen did not affect how successful testers were in finding their stages, at least not to a noteworthy extent. Question 1.4 shows the level of frustration testers experienced in this test, and it is clear that testers were very frustrated on average when using the real screen. In fact, over 75% of testers thought that the icons were too small (on top of other issues), as shown in question 1.5.

After this section of the test, users were then asked to download the prototype of my redesign and find three different stages. They were then presented with very similar questions to the previous section to be able to have an easier way to make connections for myself when analyzing the results.


Have you found all three provided stages in the downloaded prototype?

In short, the data from this section of testing the prototype shows that the redesign is definitely an improvement in terms of usability. When comparing question 2.1 to 1.1, testers were all able to find their stages inside of my prototype where as some were unable to in the actual screen. Additionally, testers spent less time in finding their stages in this prototype than they did in the actual screen, as shown in the graphs for 2.4 and 1.3. Questions 2.2 and 2.3 were asked to figure out how successful organizing the tabs by franchises was. Now, these graphs show that the tabs were pretty easily understood, but keep in mind that most of the testers in this group play SSBU, so they already have some exposure to what the tabs mean. There were only 4 testers that didn't understand what the tabs meant, but 2 of those testers were the only 2 testers in this survey that didn't play video games at all; further testing must be done in this area. When it comes to frustration, there was a huge improvement in the redesign! The average level of frustration for the redesign was a 3.4/10 (question 2.5), where the average for the original screen was almost double at 6.7/10 (question 1.4). When it comes to specific issues addressed by testers, the amount of problems that testers had with this redesign was significantly less than in the current design - just look at the percentage of testers across the board that had issues, seen in questions 2.6 and 1.5. Now, this isn't to say that the redesign had no issues at all - 13 testers thought didn't fully understand the method of organization (question 2.6), and more than 50% of testers said that the most frustrating thing about the screen was the most frustrating thing as seen in question 2.7 (although only 9 testers total thought it was even an issue at all). There were also some comments about the constant switching of images being very hard to watch after a while, so that's another thing to be put on the radar in the future.

Finally, I wanted to ask some questions specifically about the Favorites tab; these questions were very simple and I was really only testing to see if having a favorites tab was as useful as I thought it to be. In this section, I had testers go into the prototype and find 3 stages they liked and add them to their favorites. I then had them try to find those stages in the real screen to make them realize that there was no equivalent of a favorites tab in the real screen; ideally they would find this task to be frustrating.


How difficult was it to find your three favorited stages in the original screen?

-> level of difficulty ->

Unfortunately, question 3.1 doesn't tell us a whole lot. The responses are all over the place, and the average level of difficult is a 5.4/10, which is right around the middle. Now, I had expected these results to be towards the higher end, but my guess is that testers got more and more familiar with the screens and stages as the test went on, meaning that they may have had an easier time finding stages for this question. This is especially because in this scenario, they are looking for 3 stages that they liked, which were all shown to them on a large scale in my prototype, giving them a good image of what to look for. Now, question 3.2 does show us that every single tester (except for 1) did like the addition of the favorites tab! The one tester that didn't like it is was determined to be a dud; they only answered the extremities of every question and even responded to one answer my calling my survey a word that I'd rather not repeat. For those reasons, I will not be considering that tester's answers seriously; thankfully their responses did not hold much weight and didn't affect trends in a major way anywhere in the survey outside of this one question!




Doing even more card sort testing for clarity.

While card sort testing did take up a large part of this project, that was only because of how long it took for each test to happen; in total, I was only able to get 6 testers to do cart sorts, which is part of the reason why I had each one of them do two card sorts for a total of 12 card sorts. Not only was the volume testing lacking, but also it seems like organizing by franchise is still a bit unclear as the "best option"; according to my final testing results, players that didn't understand what the icons meant at first had trouble understand what they were over time. This could just be an issue solvable with more visuals and indications in the build itself, but it's also worth testing out different organization methods to see what sticks the best with the most amount of users.

Addressing new issues for the best possible experience.

In the testing done for my prototype, the results related to how frustrating the experience was compared to the original screen came back extremely positively - the average level of frustration was cut in half from the original screen to my redesign. That is great and all, but issues still exist with the redesign, primarily the fact that stages appear to be too similar to testers. On first thought, this seems like something outside my arena of expertise, since I can't change how each stage looks. But what I can do is try to come up with solutions in the UI to visually differentiate similar stages apart from one another. What this would entail at first is some sort of testing to see which stages users think look similar, and then from there trying to test solutions that make each stage stand out more.

Implementing other stage selection screen features.

In my very first wireframes, I had plans to translate all of the features from the original screen directly into my redesign, such as the ability to select what music plays on stages and the ability to change the stage's form. I also wanted to add in an "info screen" that gives more in-depth details for each stage so players can know as much as possible if they so desire. I abandoned all of this during development simply because they did not directly pertain to the issues I was trying to solve and were more so just ways to prove that this redesign doesn't lose anything compared to the original screen - I simply just didn't have the time to do that AND fix the issue at hand. But now that the issues I set out to solve have been at the very least improved upon, I have more of an opportunity to start implementing designs for these extra features with a strong base to build off on!

Website designed by Leonardo Robles Gonzalez

Website powered by Wix

  • Twitter Social Icon
  • LinkedIn Social Icon
  • SoundCloud Social Icon
  • YouTube Social Icon
  • Social Icon