
PROBLEM CONTEXT
After playing Pictionary with my friends, I noticed that our choice of Pictionary app led to a lot of arguments and cheating during gameplay.
I decided to design a different app experience to reduce arguments and cheating.
ROLE
Solo Designer.
End-to-End Product Design.
TIMELINE
2 months
SOLUTION
Picto is a first-of-its-kind mobile app designed to facilitate Pictionary gameplay.
FINAL OUTCOME
When I presented the final solution in front of users…

Outline
1
Empathise
Backstory
Setup
Research - Pain points
Research - Personas
Research - user stories
2
Ideate
Brainsorming
Solution
Competitive analysis
3
Prototype
Information Architecture
Wireframes
Branding
Final Designs
4
Test
Usability study
Measuring success
Outcome and conclusion
Backstory - How I discovered the problem
Friends gathered to play a game of Pictionary….

We picked a bad mobile app to play Pictionary.
Arguments ensued…

I decided to design a different app experience for it.
Let's dive in…

Let's understand how the game is played

I immersed myself in the gameplay to deeply understand the pain points
Meet the Riatans

So, what do the Riatans need?
Addressing each of the pain points individually

The solution I decided to go with
Let's lay out a basic hierarchy for the app

Let's draw some inspiration from our competitors
Improving our solution with user testing and feedback.










Sketching early ideas on paper
I went on to ideate what Picto’s app would look like.

Some constraints I was thinking through:
The emotional state of the Artist.
Artist holding the phone in 1 hand, are the correct buttons reachable to the thumb?
Should we swipe left/right OR top/bottom?
Creating a fun brand ( Full details here )


The first set of designs
Since the visuals are relatively simple, I decided to design the screens and use them for a usability test instead of using a wireframe clickable prototype.





This design solved a couple of problems:
Toggle between red and blue teams.
Blue and red colors were chosen in such a way that they barely met the WCAG contrast guidelines. The contrast ratio is 3:1. This is cleverly using accessibility guidelines.
The swiping interaction meant we could count the number of correct guesses.
What I learned when Riatans used my app
I immediately noticed some issues.
😓 It might be difficult for the artist to make the split-second decision between the right and left swipe.
😓 There is no point in having two different colors for the teams (on the app)
because
If I can't have a 2-way swipe, then
I can't have the artist count the correct guesses.
This leads to :
Fewer colors to manage on the app ( Good )
Not restricting to 2 teams anymore. You can have more than 2. Keeping it flexible (Good for the app’s scalability)
😓 App cannot avoid counting disputes
The count dispute can easily be managed offline because players have a memory of recent events.
The app cannot avoid disputes even if there is a design to count the correct guesses.
It's worth leaving it out of the app entirely so that we can prevent frustration when the artist uses the app.
😓 “Can I play without Watcher as well ?” - a Riatan
This one statement caught my attention. Riatans want flexibility when it comes to using an app. So I decided to design the Watcher mode as an optional feature.
So, the designs evolved…
Splash screen
A fun animation to introduce the user to the app.

Artist mode





The start button starts with a countdown, which helps the Artist prepare to become alert.
I make sure that the start button and the cards are in the “Natural” thumb zone to address the accessibility issue of holding the phone single-hand.





Watcher mode
A fun animation to introduce the user to the app.

Watcher syncs the card's data and relays which word is being shown on the Artist’s phone app.




