Don’t Make Me Think

Most appropriately, at the midpoint juncture of the “Software Development on Evolving Platforms” module (which most seem to not know what this is but instead know about the “Facebook module”), we arrive at one of my favourite parts of software development – User Interface Design. Quoting from an expert, “It’s like golf: a handful of ways to get the ball in the mole, a million ways not to.”

In this particular case study, we analyze the first iteration of a now defunct Facebook Application – Get Help. The concept is straightforward – it is a portal to help you get help from your friends and their friends. Think Yahoo Answers that leverages on your social graph on Facebook. A screenshot of the application is shown here:

Given that most readers of this entry would probably have read the case study already, allow me to jump right into the analysis of the application’s user interface. (Do send me an email if you would like to know more about the case study.)

Don’t Make Users Think!
Before performing the analysis, “Don’t Make Users Think” is a key principle that we need to agree upon to assist us in making comments about the application. This principle roots from the following observations:
1. Web users have short attention spans and will “bounce” if they don’t see what they want quickly.
2. Web users scan instead of read (unless its an information site).
3. Users like mindless choices – e.g. Books, Electronics or Toys

First Impressions
Moving onto Get Help, an immediate look gives me the impression of the average game/entertainment application on Facebook. The questions that come to my mind include “Are the people answering my difficult question kids?”, “Is this a professional site?” (Compare this with Wikipedia, Investopedia, or Adobe’s software tutorial sites.)

Navigation Panel
Looking at the application in detail, we first look at the navigation panel that is on the top of every page and a precious piece of real estate on the application. (Comments marked in red).

Suggestions:
1. For branding & as a reminder of the location, the logo (or design) should headline (usually top left)
2. Key Functionalities (Overview, Recommendations) need to attract visually – perhaps shape it as a button to let users know its “click-able”
3. Peripheral capabilities (Badges, Profile, Stats, Invite) might not be used as often – shouldn’t take as much real estate space
4. Thinking is required to understand the links as well (Invite.. who? Stats.. of what?)

Homepage Usage
The homepage is the landing page for all users. As such, instead of being used purely as a Query creation page, it might be good to include updates on the other key functionalities. These updates could answer questions such as:
1. What are other people asking?
2. Are there answers to my previous questions?
3. Are there people introduced to me to answer my questions?
(4. Perhaps the most recent badge can be placed here too.)
For me personally, I thought that the Overview page was more relevant as a Homepage.

“Help Creation”

In addition, it might be vague how “big” the project should be. Is a desired question: “Help needed to find accommodation in New York” or “Help needed to write Facebook application”? Also, it might have been good to categorize requests so as to create “forums” around the projects to see if similar projects have been completed previously.

Overview
In the below diagram, the arrows show how I would use the site once I see it, which could have been a shorter “path” if rearranged (e.g. section navigation moved to left).

Interaction wise, it might also have been ideal to allow users to state their interests while setting up the application so that only projects in the categories of interest to them would be shown in the feed (this brings back the need for categories in the projects).

Project Management
In this section, the layout of the page might have shone some light on the type of projects which can use this application, or has it not? What happens when the “help project” only requires someone to answer a question really quickly (e.g. needs help to debug this software)? Is there a “close project” option for users?

Enhancing Interaction through Rewards
Get Help uses Statistics and Badges to reward users by giving them Badges and featuring them on Statistic tables (similar to leader board). Assuming that there is a network of users on the application, these rewards may/may not appeal to the audience (again depending on the type of “help projects” created through the system). A professional crowd would not be as likely motivated by such a board as compared to a young crowd.

However, the cold start strategy seems to not have been solved since the invitation of friends into the application seems to be away from the process flow of the project creation, but we’ll talk about that later.

Is Facebook Suitable?
Taking a step back after the detailed analysis, is Facebook really a good place for this application to exist? What type of questions do the developers imagine the users to ask? Work related questions or fun related questions? Facebook is generally used to network and have fun with friends, so are there questions that is relevant to this general use case so that there will be people who answer the questions actively? (I won’t answer a question about using Adobe Premier while using Facebook, but I will if I am at a Adobe forum.) As an example, LinkedIn might do better to target professionals and Twitter would do better for short answer help projects.

Other Key Challenges/Suggestions
1. Cold Start Strategy
Given the fact that this is a third party application to Facebook, it must have significant value for users to want to add/try out the application. While the value of the network (or reciprocity as mentioned) will be an excellent pull eventually, there is a lack of motivation to be the first on the network. This can perhaps be solved by being really good in performing certain “help projects” and attracting an initial crowd in that category.
2. Branding
To summarize a common suggestion that littered prior comments, the team needs to identify its exact target audience and solve their category of problems. By allowing for too much flexibility around the word “Help”, users won’t know if this is the app for them or not. On the same note, the developers could reshape the theme of their application to fit the use case.
3. Use Conventions
Given that the application is trying to build an application that is an innovation in using social graph to help solve specific problems for users, the developers might want to focus on attracting, educating, and retaining users and just use conventional practices in other areas such as user interface. This way, users are already familiar with the environment and would only need to focus on the “help project” portion of the application.

Revamp and Focus
Overall, the developers of Get Help has identified a good problem – the need for a way to identify specific skill sets to help solve problems. However, there are problems of audience identification, lack of clarity in user interface, as well as a solid method of attracting new users to install the application (virality). Resolving these issues and identifying the right platform to build the application upon might deliver a solution that I hope to use!

P.S. Do Check out Steve Krug’s “Don’t Make Me Think” – It is one of my favourite books of all time, and a quick guide to web usability