Project Summary

Punch Line is a mobile game that transforms telling jokes into a competitive sport. Boxers earn points and collect jokes simply by playing. Write a good joke and others will share it, while you earn points. Hear the laughter of a nearby stranger that you just texted a joke. Tell jokes at a party without taking the stage and have a collection of all the jokes you ever heard and never could remember.  

 

My Role

Product (UX/UI)
UX Researcher
Game Designer
Branding

Team

UX Designer 
Developer

Timeline

2 months
4 phases @ 2 weeks
16 meetings @ 1 hour

Scope

Discovery
Contextual Inquiry
Define
Game Requirements
Research
User Research 
SWOT Analysis
User Personas
User Survey
Development
Information Architecture
Site Map
User Stories
User Flow
Design
Content Development
Visual Design
Style Guide
Logo
Testing
Interactive Prototypes
Testing scripts
Testing & Analytics 
Build
Agile environment

 

Discovery

DISCOVER-commute.jpg

Contextual Inquiry

The Circumstance

During my commute, I observed riders were using their smartphones doing one of three things: texting, gaming or reading/scrolling content. I wondered how all these strangers could connect in real time with each other via their phone. Suddenly a commuter burst out laughing and several people looked up with a grin and then went back to their screens. I wondered how a mobile chat game that made you laugh could connect all those commuters.

From this I derived a simple game of humor tag. A player sends a joke to a stranger or friend without the punch line. If the receiver wants to know the punch line they must send a joke back to reveal the complete joke. All jokes received would go into a player's database so that they could be shared. Players can also write original jokes and share them. Users can set filters on the type of humor they want. This simple idea became the impulse for building Punch Line.

Goals

  • Understand context

  • Activities & tasks

  • Pain points, Issues, Frustrations

  • Behavior

  • Process, Roles

  • Inputs & Outputs

 

Research

Punch Line Personas

Punch Line Personas

Bartle taxonomy of player types

Bartle taxonomy of player types

Personas

Who is a gamer? What games do we play? Why do we play mobile games? To answer these questions I created a survey and posted it on Reddit and interviewed five gamers. Validating my the finding from my research my user personas overlayed perfectly with Bartle taxonomy of player types.

The Bartle taxonomy of player types is a classification of video game players (gamers) based on a 1996 paper by Richard Bartle[1] according to their preferred actions within the game. The classification originally described players of multiplayer online games (including MUDs and MMORPGs), though now it also refers to players of single-player video games.

The taxonomy is based on a character theory. This character theory consists of four characters: Achievers, Explorers, Socializers, and Killers. These are imagined according to a quadrant model where the X axis represents preference for interacting with other players vs. exploring the world and the Y axis represents preference for interaction vs. unilateral action.

Motivations

• Users would often play games when they were waiting or alone.

• Using a chat feature was a common socialization tool of gamers during play.

• Social circle of friends would gather to play games.

• Being known as a funny person was a social plus.

• A majority of female gamers surveyed preferred enjoyed puzzle type games.

Frustrations

• Players being penalized for not responding immediately during play.

• Players had difficulty remembering good jokes.

• Players rarely shared jokes while texting.

• Funny introverts had few opportunities to share their jokes

• Being a gamer was often associated with socially awkward, introverted behavior.

• Games needed to accommodate playing game in short spurts.

Considerations

• Research data found in the User Persona's followed the Bartle taxonomy of player types

• There are currently no competitive joke telling mobile games.


Development

 
UI for MVP

UI for MVP

 
OnBording Flow

OnBording Flow

Analysis

Guided by my user objectives, I compiled a giant list of tasks in my user story. Then, I chunked the tasks into a screen inventory to form a fundamental user flow.

DESIGN-onflow.png

User Screen Flow

Guided by my user objectives, I compiled a giant list of tasks in my user story. Then, I chunked the tasks into a screen inventory to form a fundamental user flow.

1. Onboarding -> 2. Inbox/Home -> 3. Joke Database -> 4. Joke Writing -> 5. User Settings -> 6. User Match -> 7. Joke Market


Then, I returned to my user story and highlighted five MVP functions found on each screen to establish the app UI.

DESIGN-Sitemap.png

MVP Functions

Then, I returned to my user story and highlighted five MVP functions found on each screen to establish the UI and site map.

1. Search | 2. Edit Screen | 3. Setting | 4. Find Player | 5. Joke Writing


Design

Punch Line style guide inspiration

Punch Line style guide inspiration

Brand

The language of comedy has a violent vocabulary. You throw punch lines; you kill the audience, you bombed, slap stick, etc. The simple act of telling jokes is both exhilarating and brutal if met with dramatic silence. For these reasons, the game’s look and feel is based on the display iconography of boxing posters linking laughter with the excitement of the big fight.

The basic color scheme of black red and yellow blatantly mimics the easily recognizable propaganda style found in the boxing posters. The logo font of Fjalla with its lean and mean stature and tall and sharp san serif corners says authority. While the solid and strong Future Condensed font states it purpose clearly in headings. Last by not least Avenir easy and crisply communicates any text content..

Logo

The logo was discovered when searching for icons while building an early prototype. I noticed how the each boxing glove icon contained a whimsical smile all I had to do was give that smile two black eyes.

BRANDlogoB.png
BRANDlogoW.png

Wireframe

BALsAMIQ Wireframe

BALsAMIQ Wireframe

Onboarding Flow Wireframe

Onboarding Flow Wireframe

How do you play?

Research showed that the success and early adoption of any game app was based on how easy it was to play. So my first first task was creating an onboarding 3 -step tutorial outlining how to play the game. From my white board and notes, I initially built a wireframe in Balsamiq and then a clickable prototype using Sketch and Invision. Then, I ran four quick and dirty user tests to see if my assumptions were correct and that the process worked.

Finding

My user tests showed that yes the directions were clear yet were often ignored in a rush to play the game. This suggested maybe an funny guide overlay for new users might be a better solution. The biggest take away was that user’s needed a jokes to begin play. Being forced to write a joke at the beginning was a huge pain point and barrier to play that needed bridging. Providing an initial jokes incentivized other players with points and also created future opponents.

 

Testing

PROTO-2A.png
PROTO-2B.png

User Testing

Round One

From my initial user tests of the onboarding flow, I discovered that easy game play was key. I adopted a swiping gesture to mimic throwing a punches and content drawers to accommodate for small screens in my first prototype.

Findings

• UI patterns using swiping gesture and drawers were associated with browsing content.
• Users wanted a simple large button to send jokes not a gesture
• Users were overwhelmed with an inbox of jokes.
• Most users wanted a one on one match not a brawl.
• User top three functions were:
1. Searching / 2.Writing jokes / 3.Finding opponents.


PROTO-3B.png

User Testing

Round Two

From my first prototype I learned volumes and this translated into a dramatic reworking of the UI to focus on a boxing arena experience.

UI CHANGES

  1. Boxers take your corner! Upper right the challenger and lower left the opponent.

  2. Split screen. Top the joke database. Bottom the boxing ring (chat area)

  3. Punch button –middle of the screen button sends jokes

  4. Find an opponent button at the bottom (VS Belt) - populates corner

Findings

• Split screen confused users
• Users were uncertain where to tap
• Chat UI flow should be bottom up not top down
• Can I choose my color
• Understood waiting dots convention
•  Inbox or home view needed


User Testing

Round Three

Understanding what didn’t work I went to back doing some research with further contextual inquiry. From studying a game controller I learned ergonomically that thumbs are the masters of the game universe. So I accommodated those thumb wars and turned the screen horizontal.

Split screens, created split minds and confused users so I used the standard UI patterns used in Imessage.

I also worked implementing more game strategy and used gamification techniques. I added prominent score and leaderboard, time limited matches and incentivized starting and finishing fights with points.

Findings

• Horizontal screen mimicked PS2 game controller
• How chat worked was understood
• Sorting jokes flows needed work
• Counterpunch surprised
• Find opponents flows need work
•  Inbox or home view understood
• Search context via screen confused some

Build

FIND-thumb-war.jpg

Development

Punch Line is a humorous thumb war. Turning the screen to accommodate the users thumbs made all the difference in creating a intuitive and fun gaming experience. The positive feedback I got from testing and after posting the project on Slack was inspiring and led to a developer that was interested in helping me build a working prototype to use for pitching the project.

We started a Agile cycle. I am familiar with the scrum methodology so I assumed the role of product owner. At our initial sprint planning meeting we discussed the scope of the work, reviewed the features required for an MVP delivery. We agreed on a scope of an initial four week requirement cycle and a proposed six week development cycle with 7 day sprints and review meetings via Zoom on Mondays. I supplied a road map, design artifacts, feature requirement documentation and we began the project. The process initially began with few backlogs but soon ran into snags developing a back end. A steep learning curve for the developer led to adjusting the project requirement for only front end coding. The next challenges was choosing a proper framework that the would fit the project requirements. The React framework was the developers choice and a login process was built.  At this time we were approaching the end of our first cycle and I was preparing a new sprint schedule when the developer got a job and development halted.

So that, were it sits currently. Undeveloped but still loved. Recently, I have learned that a backend might not entirely be needed to implement this on imessage. Regardless, please take a look at prototype and I invite you to contact me if your interested in helping develop this project into a working MVP.