Timeline: Jun 2017 – Dec 2017

Project Type: Personal Project

Role: Visual and UX Designer

Tools: Adobe Illustrator, Figma

Skills: Wireframing, Storyboarding, UX design, Redlining, Spec sheet development, UI asset development, Iconography, Art direction

With a team of 4 others, I was brought on to aid in the development of a web/mobile app for a drinking card game. I worked with the game designer and developers in creating the layouts, assets, and overall design for the first versions of the web and mobile versions of the game. As the game was being developed, I suggested visual changes that adapted to the game’s direction. 

Hmmrd is a team-based card game in which players on opposing teams draw cards with challenges on them. The player who draws the challenge must either choose to perform the challenge or otherwise fail. If the player succeeds, they get to send a drink to an opposing player, but if the player fails, they have to drink. 

The game heavily revolved around the term hmmrd, which not only stood for the idiom of getting drunk, but also the themes of each challenge card. The themes are head, mind, muscle, random, and drink.

The game revolves around a single card and we knew that they players needed to know this specific information for each challenge:

• The number of players from each team need to be selected to participate
• The challenge name
• The challenge description
• The number of drinks that can be sent upon success or failure of the challenge

Before a challenge is read, the participants related to each challenge must be selected – so naturally, this information would be on the card-back before revealing the card. The initial designs were black-and-white to focus mainly on the layout. Our designs focused on simplicity to relay information explicitly with the goal of conveying information clearly, thus making the game easy to learn. We wanted to ensure players didn’t need to refer to a rulebook to understand what actions you’ll take next. For our card-back, we started with explicit values, but moved towards just using icons to convey and colors to convey teammates and components that need to be chosen.

The card-front had similar design goals in conveying information clearly and reducing confusion when playing with each card. Initial designs prompted that the player or the opponent would get to choose to send drinks depending on who completed the challenge, but our user testing revealed that players were getting confused during this step of the game. Players were not sure what each number referred to or which player gets to send a drink. To reduce this confusion, we simplified the drink/no drink information to just singular icons to represent whether a player has to drink or not drink on the success of the card.

Initial card-front backgrounds had illustrative backgrounds to match the theme. To follow the clear and clean design for communication, we simplified the card design by using a flat layout. The card types (head, mind, muscle, random, and drink) had corresponding colors to better match the card, but those were also removed because they did not give any useful information for the game. The game rules used to be that depending on the type of challenge, the drinks given/received would be different, but we removed that rule since it stifled gameplay. In most settings, players may not always have the drinks that the card stated, so drinks ended up being whatever people had on hand. 

As we prototyped early mock-ups, I created a style guide for designing game materials moving forward. This early guide is meant for direction for the app and website, but as we start designing the app and website, we would continue to append to the style guide.

Since the game revolved around drawing cards, we wanted to make it feel like the user was flipping to reveal cards as they would with a physical deck. Initial designs had users just tap the deck to reveal the card, and then tap again to go to the next card; however, it was not clear that this would be the correct action to do so.

As we tested, some users would try to swipe the card to the next card rather than tap the card like they did to initially reveal it. We then incorporated a swipe action that would also let players reveal/go-to the next card. However, upon further testing, users still seemed confused on their first time playing.

To remedy this, we added a button below the card deck that says “Reveal Card” and “Next Card” depending on if the card had already been revealed or not. I believe in future renditions, a quick overlaid solution to quickly educate users would be a quick on-boarding lesson to teach users how to interact with the cards.

We focused on keeping a flexible layout to iterate quickly based on our learnings. Since there is set-up required before each game, we gave a series of instructional screens before the game got to the deck. We focused on separating the UI into distinct containers for icons, text boxes, and buttons that could be easily changed out during development. 

Below, we can see screens of some of the instruction prototypes and their corresponding red-lines for hand-off. Each screen holds a consistent layout with some elements or containers shifted. As we iterated the rulebook, we would be able to change the instructions on these screens rather quickly.

Once players knew how to play the game, they found the instructional screen cumbersome and often tapped quickly through the screens to access the deck of cards.

It was here where we began considering two different user states: 

1. users who have never played hmmrd 
2. users who have played hmmrd 

Although gameplay may not change, the level of on-boarding or information during start-up is important for each user to have a seamless experience. We had to consider when users would be presented information as well as the moments where they expect to seeing more information. Because of this behavior, we ended up moving the instruction screens to an information button next to the start game button to allow users to quickly start the game while also having access to instructions whenever they’d like.

To understand which cards were liked and disliked by players, we used quantitative and qualitative methods:

After about a month of development, we were able to get a web-app developed for a working prototype of hmmrd. It used to be accessible and playable on mobile at hmmrd.party, but our team had stopped paying for the domain subscription. We used this working prototype as a way to test gameplay rules, test new card ideas, and interaction design on both mobile and web. It was much quicker to develop on web before launching our iOS app for the game.

Since then, the project has been shelved as the team has been focused on other pursuits. In the appendix section, you can see some of the screens that were developed for the game at the time.

Overall, I was happy to have joined the team to work on hmmrd since it was a small team of acquaintances. I was able to not only feel involved in every decision-making process, but also work closely with each facet of the team (developers, designers, marketing).