John Gazzini

Finish: User Experience Design

Core Functionality

If I had to describe this app to a stranger in 3 seconds, I would say: “Finish your friends’ Tweets by guessing the last word.” That isn’t a complete description, and it probably won’t convince anyone to download or even be interested in the app. However, I’m going to start with that simple core functionality and design the entire UX around it. I hope that once I define exactly how someone will finish a Tweet, the rest of the UX will fall into place.

Initial Mockup

Many people start with some kind of wireframe design tool when attempting to explain their vision for a UX. This is a great way to demonstrate how you think an app should function without actually having to build the app.

However, I’m going to take a different approach: I’m actually going to create a basic app using no code. A few years ago, Apple introduced a development tool called “Storyboards.” Ideally, this tool allows developers to visually create a high-level diagram of their app’s navigation flow, indicating how the views are organized. Then, they can write source-code that actually hooks into the storyboard file, which is useful because it tightly integrates the design with the code. So, using nothing besides drag-and-drop, I will create an extremely basic mock-up of the app:

(note that the video is played at 9x speed)

So, after around 10 or 20 minutes, I have an actual app with 2 screens. The first screen shows the user the most recent Tweets from their timeline (but does not show the actual text in the Tweet), and the second screen shows the selected Tweet without the last word. <div class="row" align="center"> </div>

I Assumed Something

I assumed that a user should be able to pick and choose which Tweets they try to finish, because that just seems more fun to me. Veteran UX designers might stop here and discuss simplicity vs flexibility (or something completely different that I’m totally missing), but ignorance is bliss, and this way just seems better. So, I made 2 screens instead of one.

Now What?

Next, I actually ran the app on my phone, just to see if it made sense. During this very first test, I am only asking myself two questions:

1) Can I see all of the information that I currently need?

The obvious answer: NO.

On the first screen, as I scrolled through the list of fake Tweets before selecting one to finish, I realized that a user will want to make a strategic decision about which Tweet they select. Perhaps they should see the current score of the user who Tweeted it (the “Tweeter”), or their success ratio when finishing that Tweeter’s Tweets in the past, or maybe even the number of other Finish players who have succeeded and failed at finishing that same Tweet. For now, I’ll make a very informal “To-Do” right there in the mockup, because I won’t actually know what’s possible before I design the Information Architecture.

On the second screen, I realized something: It might be very, very difficult to guess the last word in a Tweet. There is no guarantee that the Tweeter will Tweet in a grammatically correct sentence or even in the form of a logical thought. Just typing the word into a blank text-field could be difficult or impossible. In this situation, focus becomes important. I stuck to the plan by only asking myself if any information was missing from the screen, and I decided that I should tell the user how many letters the missing word contains, and provide a sort-of countdown that indicates how many letters they have left as they are typing. I realized there was still room for improvement, but I moved on anyways. So, after step one, here are the two updated screens: <div class="row" align="center"> </div>

2) Is all of the input necessary?

For the first screen, the only input required of the user is scrolling through and selecting a Tweet to finish. That seems unavoidable, so the answer to this question is yes. It’s worth noting that I did have an idea here for a fancy, unnecessary selection animation. But, for the sake of focus, I just made a mental note of that and decided to revisit it later.

On the second screen, this question becomes less straight-forward. In fact, it’s very open-ended, and I could do a lot of testing and think for a long time about the best way to allow a user to guess a word. However, I’m in a hurry, and I’m confident that other people have attempted to solve this problem before. So, rather than inventing my own solution from scratch, I decided to look in the iTunes App Store to see how other developers have already solved this problem.

I looked in the “Word Games” category, and there were several good apps that, at some point, require users to guess a word. Of all the solutions I saw, there were 3 main methods:

A) The “Letter-Bank”

The users sees a random collection of lettered tiles at the bottom the screen, and must select the tiles in the correct order to form the word. Example: Let’s Guess Apps

B) Full Keyboard

The user has a full keyboard and must actually type the correct word. Example: Big App of Little Riddles

C) Multiple Choice

The user is presented with several (usually 4) possible choices, and they must select one of the choices as an answer. Example: Guess the Celebrity - Quiz

Almost all of the recently featured apps in the Word Games category used the “Letter-Bank” approach. However, the Full Keyboard approach will be much easier to implement (it’s nearly done already). As for Multiple Choice, that would require the app to find 3 other believable words for each Tweet, and while I’m sure there’s some kind of online thesaurus I could connect to, I suspect that the correct answer would be extremely obvious, making the game too easy.

So, for the sake of time, I will start out with the full-keyboard implementation, and I will require the user to actually press some kind of “Done” or “Submit” button when they are finished typing the word. However, I will make another mental note to come back and test the “Letter-Bank” if I have time later.

Now that I have a better understanding of my UX requirements, I will begin to consider the Information Architecture (tomorrow).

← Previous


Next →

blog comments powered by Disqus


29 August 2013




About Me