Case Study: Get Help

This is a case study on “GetHelp!” regarding User Interface & Interaction Design.  “GetHelp!” was developed by a group of students from CS3216 in March 2008. Quoting the assignment PDF,

The core function of the app is to make it super easy and fun to discover people from within and outside a user’s Facebook network to help them with their needs and funky endeavours.

As shown below are screenshots of the initial version of the application. The developers have since redesign the user interface.

My task is “to analyze the screenshots and uncover what was the problem faced which lead to the team’s decision and how the problems can be resolved…

Figure 1: Home Page (also the New Project page)
Figure 2: Overview Page
Figure 3: Project Page
Figure 4: Statistics Page

note: The accompanied verbose description (in the assignment PDF) are not included in this blog post.

My first impression of the application is that “Hey, the icons are cute! I wanna try this out”. However further pondering leads me to the conclusion that the application is redundant. I think users might not want to add an application to do something that the Facebook status publisher can already do very well. The entry level is simply too high.

Besides, I ask myself “Why would I want to add this app?”, “What are the incentives”, “Badges? Special Nicknames?” “Do I really need these?”. In short it is non-viral and non-sticky. It lacks two of the most important feature of a successful Facebook application. More thoughts will have to be put into attracting the lead-generation.

Layout (User Interface)

The landing page is just too cluttered. I bet the developers themselves didn’t spend much time test-using the app themselves. Or their app-flow was not planned properly in the beginning. IMHO, entry-landing page should be straight forward and minimalistic (think Google). Only make available most basic feature (hide the rest under “advanced options”). I would like to take this opportunity to commend whenisgood,  it is simple and effective.

Zooming in….

  1. Usability – it is confusing – “need quick help” and “I need help with“, which is which, what it does?
  2. Top navigation bar – slab icons (on the right) + words link (on the left).  It is clearly a design is not standardised). Overall design throughout the app is standardised. Good.
  3. Red colour draws attention -> immediately users will take note of “call for help” button. Good.
  4. verbose description of options more harm than good i.e. “post to all your friends” “or, you want to hide it from someone specific“? Most users are familiar with facebook users & privacy selections -> simulate it OR use supported Facebook API.
  5. Statistics Page– make the numbers more prominent (bold it or stylise it)
  6. Statistics Page – maybe a simple description of what is “fire” – I seem to have a hard time understanding the metaphor

In short, I think the landing page should be as simple as one simple text-field and a button to submit (as shown in the image below)

Next, the advanced options will only be made available if the user request/click for it.  Better still, the developers should leverage the status “Publisher” to lower the entry level barrier. This way, users wouldn’t have to change their habit of posting stuff onto their Facebook wall. If advanced details are needed, it is possible to amend the published wallpost with the captured post instance.

Features

I notice a “change  image” feature @ the landing page. I wonder how many images are there for users to choose. Does it support user-upload image? If yes, how does the quality-control work?

The SMS feature is commendable if it works (I wonder how they got it working?). Besides, I think it’ll be too much of a SPAM if this application becomes real popular.

Integration with twitter is no easy feat too. Let’s say someone on twitter saw the tweet and wants to help, is this app able to capture that help instance? What if the twitter user doesn’t have a Facebook account?

Principle

There is a fundamental contending issue here. I think if a person really wanna help another person, they wouldn’t want to be seen as to help so as to earn badges. Therefore, the badge/nickname incentive might just backfire. On the other hand, if a person really wants the badge/nickname so badly, experience tells me that they might not have the credentials to help that many people. Unless this issue is resolve, I think the application will not be able to take off.

One more thing, how will this app be monetize? The only way I can think of will be something like the now defunct Google Answers. But is that really what the developers want to achieve?

All in all, I think the take back from this Project Case Study is that minimalistic is KING when it comes to User Interface and Design.  Plan well = half succeed. Cluttered = no good.

Published by

joshuatj

Digital Preservation #digipres. IT guy at @AFA_Archive Asian Film Archive. Malaysian news. PC games.

3 thoughts on “Case Study: Get Help”

  1. Hey Joshua!

    So in your opinion, what do you think could be done to make it more viral and create lead-generation? How would you implement this concept if it were you? 😀

  2. Hi Su Yuen, thanks for commenting.
    Virility – if the app is cool, it gets viral. (Sometimes it doesn’t have anything to do with the app’s feature)
    lead-generation – invitation-only? exclusivity e.g. Gmail when it first started.

  3. Pingback: joshua.ng.; i.am.

What do you think?