design exercises

Shop heroes redesign (mobile)

I started with a redesign of their player summary based off the existing IP, Shop Heroes. I redesigned all the icons and wanted a more elaborate icon set to be more crisp and clear but still in the current SH look and feel. I broke out the character and reorganized the stats to be better grouped in closer categories that related to each other. I included a player blurb for player customization for a bit of flare so players could set a note for the public visitors. Added pagination since this is a browsing friends view. I tried to stay current with the existing style while updating the visuals with HD graphics.

gems frontier redesign (mobile)

The previous design was heavily based off of Clash Royale.
I changed up a few things that I thought even Clash Royale could improve on.

• I made the currency headers slightly bigger for better readability since this is important information for the player and for monetization. I moved settings and news to the header to make room for the profile bar.
• I tried to organize the player info better by combining the player portrait and level progression. I grouped all the player info closer together. I moved the Arena name to right about the rank since this actually is directly associated to the player rank. When I was playing clash along with many others, no one really remembers what rank number they are exactly, especially since it can be a large threshold. What was a better representation of how good you were, was what arena you were in.
• I simplified the UI by removing the progress bar and moved it to the Train button since this is something only a new player would see the first few times they play until they are out of training. There really isn't a good reason why it needs to have it's own dedicated bar when this isn't a mechanic the player will continuously see in the future.
• Since the Training button will change to the Battle button, this is easily solved by keeping the main CTA here.  I reorganized the bottom navigation slightly, made it slightly bigger and gave the current page a select state so it's very obvious what page the user is on.
• I remember when I was playing clash a lot, I intuitively wanted "Battle" to be on the far right. The main CTA is better read intuitively at the bottom right. The eye is trained to read top left to bottom right which is the most prominent spot. This will be the most used spot next to Clan/Social and Deck building.
• Overall I went for a more friendly and inviting style. I rendered everything with a vector base and color over to soften lines for the overall look and feel.

pvp Ranking rewards (mobile)

This was a redesign of Cloud Cade's old Ranking screen with no hierarchy. 

• Having played a lot of MOBAs and games with ranking and leaderboards, my initial instinct was to move Rank 1 to the left and the ranks read from left to right. After some research and comparison, most games have the highest rank to the right for the chase, so I kept the ordering.
• I added a focus state that is more clear which rank a user would be on. I organized the brackets and rewards by highlighting the rewards and separating the rank numbers.
• If there is a concept of collecting pvp points or elo score, I would use the sword icon displayed next to the score listed in the bracket. That way the user will know exactly what their score is and how it corresponds with this bracket. This would make progression more of a chase and easier to track.
• I added names for each bracket to give the user a better experience of placement and tier.

Trading Card Game Wireframe Skin

I created a wireframe for a Trading Card Game based off of a set of requirements:

HD image as the hero
Attack Power
HP
Star Level (Rarity)
Name of card
Movement Point
Initiative Point
Card's special ability

• Comparing current card games out there, having 4 stat numbers is a lot to show. I did not want the user to have to look all over for this info, so I prioritized what was the most important. I knew the worst case scenario is placing each stat on each corner. That would be the least readable, no hierarchy and confusing to the player because they would not know what to focus on.
• I wanted to showcase the Initiation Point as the most important stat information for the player to base their decisions on using this unit. With that in mind, I kept this top left.
• Next would be the Attack Power. I thought this would be best associated with the name of the unit closely followed by the rarity. I added the weapon/attack type behind the Attack Power.
• To convey weapon and attack type, I added a sword in the base to indicate this is a melee sword character. If this was an archer for example, this icon would be replaced with a bow and arrow.
• For the rest of the stats, I wanted to make sure these were grouped fairly close to the IP and Atk. To leave room for the description and keeping that area uncluttered, I settled on left justifying next to the portrait, even if this portrait is 3D and has vfx, this can still be made readable.
• Overall I wanted to layout the info to be the easiest to read from top left to bottom right.

Random food picker App

Overview

Description

Finding food for a large group is often a difficult task. People have different tastes, price limits, etc.

Goals

Design an experience that helps the group to make a quick decision on where to eat that satisfies everybody.

User Stories

Hanging out with 6 friends who are getting hungry. We want to get something to eat but can’t decide where to go.

1. As a user, I would like to see a list of recommendations based on the group’s preference.

2. As a user, I would like the app to make the best decision for us when the group cannot decide.

Surveys and Interviews

User Surveys

First off, I did some user surveys based on the user stories. I gathered survey from around 10 people.

Findings

To find answers to our problem of people being indecisive about where to eat, I needed to get some info to pin point what would be some of the core functionalities to help with this. After gathering some info, I took a tally of what the top deciding factors were for users when normally deciding on where to eat in a group. For Story 1, There was a huge list of deciding factors based on my notes I took. I cut down the list and prioritize what was the most prominent features everyone mentioned. For Story 2, A lot of people brought up a voting system, and normally use polls.

1. What are your main preferences you normally look for in a lunch spot when deciding in a large group? What would some of these preferences be?

• Food Preference (including dietary restrictions) *******
• Distance/Location *****
• Time *****
• Group friendly ****
• Reviews/ratings ****
• Sit down / Take Out ***
• Price **

2. What are some of the important things you would want in an app when deciding where to eat as a group?

• voting system 
• poll or spinner
• ability to reroll

User Journey

After the survey, I did a quick user journey in Lucid Charts of how I would generally lay out the flow and what content to include.

User Goals > Select Preferences > Results > Output > Decider.

For the decider, I was debating between a spinner and a poll since users seemed to like a voting system. However keeping in mind the user story #2, I wanted to pick the most unbiased and quickest way for a group of people. Having a random roll is basically like flipping a coin.

After the User Journey I did a quick flow chart and wanted the ability for everyone to give input, and have an easy way to share/participate without having to download the app. I had a clear user journey but ended up confusing myself with too many features when I started to work on my wireframes in XD.

User Flow V1

For the user flow V1, I went through two prototype click through iterations.

Click Throughs from XD

I normally do all my click through and prototypes in 1080x1920 since I do both wireframes and comps in this format normally. I always test these on a phone. Normally at work I would use a iphone 5s, but I was using my personal pixel phone. v1 and v2 are oversized,

Somethings I knew I wanted for this app:

1. I wanted to call it ToothPick because I thought it was cute.
2. Have the ability to share this app very easily without everyone having the app. The idea is for one person to have this app as the leader and to be able to share via tinyurl or through other messaging apps. The guest would click on the url and it would take them to this group instance. I did debate whether having the tinyurl was even necessary but left it in there because it was nice to have and I did see myself use it when I used dropbox.
3. I wanted this to have googlemaps integration since everyone was use to some kind of food app that already had reviews and pictures. 

Click through prototype V1:

• In v1, my goal was to have one lead user who would start the app, start the group, and be able to start inputing their own preferences or share at the same time. 
• I had some user tests and they found this confusing. People were clicking on “preference” instead of "share" first. It seemed a bit confusing and out of order even though I had given the user both choices.
• Also I knew there was inconsistency with the button locations. Some CTA were on the bottom while some were on the top right. Being able to share and select preferences at the same time was getting really messy and confusing. I decided to stream line that a bit in v2.

Click through prototype V1:

In V2, I included the entry paths for someone who owns the app and someone who is entering as a guest when someone shares the link with you via msg or which ever app they preferred.

• As the leader, the user would create a new group, name it, limit the display choices per person to show as the output at the end so there would be a list of choices to choose from everyone.
• Once a group name is typed in, the add group button will be enabled.
• From here, it kicks over to the share feature. The user can now decide to share this app with their friends from a tinyurl (copy paste) or by smart searching on their device by typing in their name, number or email. 
• I was looking at the dropbox, google photos, text, and adobe apps to see what they did with sharing contacts. Dropbox was the most accommodating. It was smart enough to look up contacts that were linked through email, facebook, addressbook, etc. I went with that method.
• I had the "next" button always active because I wanted the user to be able to skip this step if they wanted to start inputting their food preferences first before sharing.
• If that was the case, the user can add their preferences next.
• Once the user was at the results page with the list of restaurants, there is a share button on the top right to share if someone was forgotten in the process.
• In the results page, "pick for me" was the random pick. When a restaurant was picked, the user can either reroll, or click on the "Social Fusion" results that took you straight to google maps and be on your way.
• As a guest, the user would receive a shared url via text msg or whatever other app of choice.
• The flow is a lot simpler and goes straight into the preferences.

Findings and Test Results:

• The dubious part of the guest flow is how the guest user would know as they are "waiting on results". Initially I wanted the app to sync up with the leader and everyone would see the roll when the pick was happening.
• Some of the buttons placements were still inconsistent.
• The challenging part of food preferences is not only trying to figure out whether to present preferences first, or sharing first but also dietary restrictions is a big deal. Some users thought it was backwards where preferences should be first, or sharing should be first.
• I also wasn't sure if I wanted to add another toggle at the end to only show results in the running with certain dietary restrictions. Part of me was just creating a russian roulette and have everyone just have the same odds of flipping the coin.

User Flow V2

revisions

• Based on the feedback from Prototype v1 and v2 that were based on the first user flow, I realized I need to streamline the flow since it was way too confusing. I was trying to allow users to share or customize the food preference at the same time. There were also various issues I still needed to solve. For instance, the other for selecting food preferences feels like it should be first, however I wanted to be able to filter for vegetarians at the end. That can't happen until after everyone has selected a preference. People could be waiting around forever waiting for each other. At the end, what is stopping this group to use google maps or yelp instead of this app? I decided to cut sharing and just focus on having one person be the driver for the group. Cutting out sharing entirely helped me focus on the core purpose of the stories. 
• I got rid of the guest name, and leader name. The group really only needs one person to lead the group and drive the app. 
• User would start on landing page, and can create a new group or pick a previous group.
• This time the drop down is limiting the list of options to pick/roll from at the end after the results.
• Since only one person is driving the food preferences now, these preferences are based on the group input. Since the scenario is everyone hanging out, everyone can be vocal and have a say in options especially since there can be more than one option to check off in the drop downs for cuisine and dietary restrictions.
• This solves having to figure out the dietary restrictions group toggle at the end and filters truly do reflect the group preferences.
• After the food preference filters, the results page will show X number of restaurants and the user is noted to choose up to 10 choices to pick from at the end. 
• I was also missing a few things at the end of the flow. I knew I wanted the option to reroll, Navigate when everyone is happy with the choice, and then an exit point.

Click through prototype V3:

I adjusted this version's click through and resized v3 so it's easier for people to preview on a phone and computer.

• I decided to scrap the sharing feature completely. This wasn't necessary. The group really only needs one person to lead the group and drive the app.
• I got rid of the guest name, and leader name.
• User would start on landing page, and can create a new group or pick a previous group.
• This time the drop down is limiting the list of options to pick/roll from at the end after the results.
• Since only one person is driving the food preferences now, these preferences are based on the group input. Since the scenario is everyone hanging out, everyone can be vocal and have a say in options especially since there can be more than one option to check off in the drop downs for cuisine and dietary restrictions.
• This solves having to figure out the dietary restrictions group toggle at the end and filters truly do reflect the group preferences.
• After the food preference filters, the results page will show X number of restaurants and the user is noted to choose up to 10 choices to pick from at the end. 
• The list output is the same flow as v1 and v2 except now this is much more straight forward and no waiting on others to populate their part of the list.

Visual Comps

For the comps, I usually design in 1080x1920 for high fidelity in mobile.

For references, I looked at other apps and UI art for inspiration I'm normally a fan of more simplistic design and styles and wanted to keep it somewhat minimalistic.

Comps V1

1. Landing page: I wanted this to be a fun looking app and very minimalistic. I started out creating vector styled silhouettes of food items. I basically started with a skin of my wireframes in mainly green since it was the most calming color in the style guide. I tried adding some complimentary colors but nothing but the yellow seemed to work well.
2. Group Preferences and Popup: This version seems pretty stale and still felt like wireframes.
3. Testing this out of the phone, the landing page and the create group page didn't feel like they were part of the same family and didn't look like they went well with each other.

Comps v2

1. Landing Page: I decided to scrap the silhouettes and stick with images since it gave it a more mature look instead of playful.
2. Create your group: I updated the create group page so the button and the name entry is on the same spot. With the same backdrop this felt a lot more cohesive.
3. Group Preferences: Since the preference page was feeling really stale, I decided to group categories up into boxes and give the background some texture with some photos of food, naturally.
4. Preference Popup: I wanted to redesign the popup functionality a bit to feel more integrated with the Cuisine/Dietary restrictions category. Instead of a direct popup, this version is basically a drop down menu while integrating the original button as a header. The +/- opens and closes this window, or the user has the option to press the "OK" button as reinforcement after filter selections are done.
5. Results: I knew I wanted to have more fun with the results page. Even though scrolling horizontally may not work the best in this scenario, I thought this presentation was more visually appealing. I thought about using dots (...) as pagination, but representing 19 dots wasn't going to look good. One option is toggling to a list view, but for the sake of time, I didn't do it. Selection method here is selecting on the bottom instead of a standard checkbox. One thing I was thinking about was the ability to click on the restaurant card to take you to google maps for more details. But at that point, the user would just use google maps and that isn't the point of this app and doesn't fulfill the user story. The point of this app is to make a decision for the indecisive. At this point, the goal is to make a decision on where to eat.
6. Pick: At this step, after the pick has been selected the user can decide to reroll as many times as they want, but once everyone is happy, the main call to action here is to click on navigate and this will take you straight to google maps.

Afterthought:

At the end of this exercise, I would have tried to spend more time on the user surveys to get more accurate answers.

I usually spend a lot of time during the wireframe phase and ended up spending too much time on this part, which didn't give me as much time for skinning. I would have liked to spend more time and had more fun on playing with different creative ideas on the app presentation and visuals including animations. Overall, initially I was really overwhelmed with all the features I was thinking about integrating and realized I spend too much time on trying to get the sharing feature working when I ended up cutting it out and streamlining it. Simplifying made everything more clear and focuses on a flow that will basically fulfill the user stories.