This is a case study I wrote as a handout to accompany a presentation I gave about User Interface and Interaction Design. The presentation slides are at http://www.slideshare.net/suyuen/get-help-ui-and-interaction-design-presentation

1. CS3216, AY2008/2009, Semester 2—GetHelp! 1
National University of Singapore
School of Computing
CS3216: Software Development on Evolving Platforms
AY2008/2009, Semester 2
GetHelp!: The Inside Story
Date issued: 2 March 2009
Interaction design is the art of ”defining the behaviour of products and systems that a user can interact
with”. It is the process of simplifying and making the learning curve of a system as flat and intuitive
as possible with a higher focus on usability and less on aesthetics. The term was first proposed by
Bill Moggridge and Bill Verplank to introduce the concepts of industrial design into software interfaces
as well. Today this concept is being practiced not only among systems and softwares but also the
growing space of web applications.
You were asked to evaluate the initial design of GetHelp! as a case study. This document is an
excerpt from the CS3216 Final Project report for the GetHelp! team.
The major problems we faced:
When the application was launched, we faced a few major problems which were mainly from 2 areas:
user interface(UI) and interaction design. This report is a record and account of each of the problems
faced along with our solutions (aka lessons learnt) for them (Note that these solutions may not be the
best solutions but rather one of many possible ones).
Lesson 1: Too many choices and aesthetics cause confusion.
Figure 1: Home Page Figure 2: Overview Page
The above pictures show only 4 out of 20 over pages that we had in the initial UI. As you can see, we
had lots of graphics to represent various elements and also numerous functions. For example, our

2. CS3216, AY2008/2009, Semester 2—GetHelp! 2
Figure 3: Project Page Figure 4: Statistics Page
Statistics page itself had 5 different sections with 5 different functions which the user could explore
and utilize. We thought that the graphics would make the page aesthetically attractive for the user
while the functions would provide choices and flexibility.
When we came to user testing however, everything failed. One question from our testers was “What
is this? What am I supposed to do?”. Yes, the UI was very attractive. People were attracted to find
out more from the combination of graphics and colours. However, there were too many points of
attraction which left the user confused about which part of the page to focus on. Every page had links
leading to 5 new pages and functions which turned out to be an ”information overload” for the user.
They had too many things to digest and were left clueless and confused.
Taking in from the feedback collected, we went back to the drawing board and redid the entire ap-
plication design and ended up with a brand new app that contained only 4 tabs at the top, 3 basic
functions and 5 pages in total (including the invite page). With the new UI, users could immediately
identify what the application was about and how to use it as their attention was focused on the yellow
box at the upper part of the page.

3. CS3216, AY2008/2009, Semester 2—GetHelp! 3
Figure 5: The new, cleaner and waay less congested UI.
Lesson 2: Users need guidance
In the words of Professor Andreas Weigend, users are silly. They do not know what they want and
you need to tell them what to do. An example he gave during a talk was that instead of asking users
to invite their friends, why not give them a number? Like 20. That way they know what to do and will
not spend too much time pondering how many people to invite.
We made this “rule” a major element of our revised user interface with a focus on guiding the user
with every step. For example, when the user first visits the homepage, only one part of the ”new
project” box is presented to him as shown below.
The “Reward your friends for helping you!” is displayed on the top to give users an idea of what the
app is used for. The “I need” words followed by the textbox is used as a guide to show users what
kind of content should be entered into the textbox, i.e. something pertaining to a need they have.
After filling in the textbox, another section of the box appears to guide the users on what they should
do next. In this case, it is picking an emoticon.

4. CS3216, AY2008/2009, Semester 2—GetHelp! 4
The final section then appears where users will pick a reward for their helpers!
The above sequence of diagrams is just one example of how we guide users and provide suggestions
to the next course of action while educating users, in a very subtle way, about the features of the app.
We see every user interaction as an opportunity to get the user to perform another interaction.
Lesson 3: Creating context from user interactions
As mentioned in lesson 2, “we see every user interaction as an opportunity to get the user to perform
another interaction.” Why do we place so much importance in this? We built the application in such a
way that every action a user performs creates context for another user to interact with our system.
For example, after a user posts a project we encourage the user to poke around and check out the
projects initiated by others. If the user offers help, writes on the comment wall or wishes someone
luck, an e-mail notification is sent out to the project initiator and a feed is sent to all the user’s friends.
The e-mail notification creates an opportunity to get the project initiator to ”come back” while the feeds
create one to spread news to both existing and potential users.
The example demonstrated how we are creating value out of a user’s interaction with the system for
others. To us this is a very important element to take into account when developing an application
to maintain the user engagement loop while also allowing users to create value for your app (which
honestly reduces quite a bit of value-creation work on the developer’s side).
Lesson 4: Focus a user’s attention at key areas
One of the most important element of our app besides being able to post a need is having users
respond to the needs of others. Without this interaction our app is pretty much useless because
initiators will be gaining nothing in return.
Below are 2 screenshots, both showing the project feeds of other users from both the old and new
UI.

5. CS3216, AY2008/2009, Semester 2—GetHelp! 5
Figure 6: Feed from old UI Figure 7: Feed from new UI
In the old UI, users did not even realize that the feed on the left was projects posted by others. All
they did was scheme through the bunch of text and moved to another page. Some of them had to
view the page 3 times before noticing some interesting posts. There was nothing in the old UI’s feed
that caught their attention.
In the new UI, we asked project initiators to select an emoticon to represent how they are feeling
about the need they are posting. This was then put onto the feed to attract the attention of others
who are viewing the feed to stop, read what the emoticon is saying and focus their attention to the
left part which displays the user’s needs. Is there any other reason why we used emoticons? Yes, it
is because emoticons are something that users can relate to easily. It has been used widely in the
internet chat world for users to express themselves making them easily identifiable and understood.
We learnt that placing something that has this impact was extremely effective in focusing a user’s
attention at key areas of a page.
Lesson 5: Meaningful incentives
A hard lesson we learnt was that awarding users with flashy, cool, stylish-looking incentives do not
necessarily work all the time. Why is this so? Lets look at examples from both the old and new
incentives.
Figure 8: Old incentives Figure 9: New incentives
We have on the left a badge that is awarded to users when they receive 10 “cheerful” compliments
from their friends while on the right, we have virtual “items” which project initiators give to users who
help them out. From a developer’s point of view it seemed that the old incentive would be more
valuable as it was more “rare”. However, users felt that getting a reward from the system wasn’t that
great a value. They were more thrilled when they received rewards from their friends especially when
it is “kisses from a certain girl” friend of theirs. Users saw more meaning and value in personalized

6. CS3216, AY2008/2009, Semester 2—GetHelp! 6
rewards from people than the system. Also, the old incentive was a promise of something a user
“might” potentially get in the future if he actively helps others but the new incentive was more of
something they’d be able to get in a much shorter time frame for much less effort. This is also the
very reason why we displayed the incentives right below the project statement. When users can see
what reward they’ll be getting, they are more ”impulsed” to contribute to the project.
Lesson 6: The Cold-Start Problem
As mentioned earlier, most users posted frivolous needs when they first started using the app. We
conducted some research into this by directly contacting some of these users. The reason for it was
that when they added the app, they wanted to test it out but did not have an actual need. Hence they
posted something random related to what they were thinking/feeling at that time. Another reason
we identified (thanks to the advice of Professor Ben Leong) was the needs being shown to users at
the time of adding the app. We, the developers, were ourselves posting frivolous needs that were
guiding the users in the wrong way. After replacing our needs with more serious ones, things started
to improve.
The next problem we faced was people not offering any sufficient help. Many users thought that
offering help meant physical help when it could come in any shape and form. We applied the ”Show
by example” method here again but this time we did not do it alone. As the scope of knowledge of our
team was quite limited, we engaged a group of resourceful people from varying backgrounds (politics,
design, technology) to become ”active helpers” in the community. They demonstrated that help could
be given in a verbal form (e.g. comments, sending messages), sharing the project with others and
referrals. This proved to be quite fruitful as we started seeing more users following the footsteps of
these “active helpers”.
Summary of lessons learnt:
To summarize the lessons we learnt from working on this application, below is a diagram containing
the 4 main principles which explains how we designed Get Help. Do note again that the solutions
proposed may not be the best solutions and may be only one of many possible solutions. However,
we do hope that this case study has highlighted the importance and some key points of user interface
and interaction design in keeping things engaging, intuitive and simple for the user.