Upload
dangdan
View
216
Download
0
Embed Size (px)
Citation preview
EECE 418
Fantasy Exchange
Pass 2 Portfolio
Team Ovthree
Tommy Tsz Kiu Wan Yawei Li Nenghao Lin
41720103 56674104 77222099
Table of Contents
Section 1: Prototype and Re-Design Rationale ................................................................................ 1
1.1 Redesign Rational ............................................................................................................ 1
1.2 Additional Analysis and Evaluation ................................................................................... 3
1.3 Prototype Illustrations ....................................................................................................... 5
Section 2: Plan User Evaluations ........................................................................................................ 5
2.1 Evaluation Protocol ........................................................................................................... 5
Section 3: Tasks and Requirements ................................................................................................... 7
3.1 Subjects ........................................................................................................................... 7
3.2 Evaluation Results ............................................................................................................ 8
3.3 Final Design Rationale & Discussion of the State of the Design ......................................11
3.4 Reflection on the Design Process ....................................................................................12
Section 4: Resource Management ..................................................................................................... 13
Appendix I: Low-fidelity Prototype .................................................................................................... 15
Appendix II: Medium-fidelity Prototype ............................................................................................ 19
1
Section 1: Prototype and Re-Design Rationale
1.1 Redesign Rational
In Prototype 1, the target users of our system included all the people aged 20 and above who
are interested in stocks. To satisfy the needs of the potential users, we attempted to design a
system that has a simple interface and provides all the most essential features a stocks
application would have. However, our system did not have an emphasis and the mental model
was not very clear.
The first thing we learned from Prototype 1 is that an application needs to be focused on the
real needs of its potential users. It is difficult for designers to see the real needs of users without
involving real users in the design process. Our design from prototype 1 failed to identify a
concrete group of users, as different users will be expecting completely different functionalities
from the software. For example, a watchlist focused stock information software will need to
focus on helping the users track their interested stocks such as notifications for when stocks hit
target prices. On the other hand, a portfolio-focused application would take focus on user’s
portfolios, and the information for a portfolio is completely different from a watchlist. A portfolio
focused application, should display statistics to help the user understand their investments.
Since our group has no real experience in trading stocks, or any professional knowledge about
the financial market, we decided to take a new direction and change our design to a game,
which simulates the real stock market. The idea is similar to the popular fantasy sport game,
where participants act as owners to build a sport team that competes against other fantasy
owners based on the statistics generated by the real individual players or teams of a
professional sport. Our newly designed fantasy stock game would enable users to experience
the stock market using simulated currency, and users competes against other players based to
the statistics generated by real stock statistics of the real market. The idea is also similar to
gambling related simulation games such as slot machines or poker games. It gives users the
thrill and sense of achievement of the real games, without having to risk their real money. The
target users would be people who are interested in financial market, but do not want to take the
risk in buying any real stock.
We think one of the most important aspects of such games would be the social functionality. It
has to be easy to compete with other users, either users’ friends or any other players in general.
An easy way to achieve this would be connection to an already well-established social network,
such as Facebook, Twitter or Google Plus. The game would retrieve users’ information
automatically, and find all their friends who are also playing the game. Another important aspect
of this game would be responsiveness of the stock statistics. Whenever the real world statistics
of stocks varies, the data in the game need to reflect the changes immediately.
After we get more information about users’ mental models about simulation games and stock
market in general, we will create a medium fidelity prototype which will include a semi-functional
user interface, with fake stock statistics and fake user data to demonstrate our system, We have
many options for the tools to use for a functioning prototype, such as Visual Basic, html,
PowerPoint, tcl/tk, flash, cocoa touch on iOS etc. Based on our team’s proficiency and
experience, we choose to use Android SDK and Java based APIs to build the prototype on
Android platform. We are aiming for a horizontal prototype, which includes all the main
components of our interface. This gives the illusion of a fully functional prototype, but without
using and fetching any real data.
In attempt to determine whether our system becomes better or worse, we need to measure how
intuitive and functional the UI is as well as user’ satisfaction. In order for us to gather these data,
we choose to conduct the experiment by asking users to do some tasks with the application and
querying them with questionnaires. The details about the experiment can be found in Section 4.
1.2 Additional Analysis and Evaluation
Since the UI of our system needs to be redesigned, we have done a cognitive walkthrough to
evaluate the new UI.
Questions:
Q1: Will the correct action be evident to the users via their existing mental models or via the
system image?
Q2: Will users connect the correct action with their goal, either via their own mental models or
via its description?
Q3: Will users interpret the system’s response to the chosen action correctly?
Q4: Will the users’ mental models be affected? Will new concepts be added, or existing
concepts lost?
User Action 1: Register and login using Facebook
A1: Yes. Logging in using a well-established social network like Facebook is a very common
action in modern mobile apps. The mental model is similar to most systems that requires
logging in, which users should be already familiar with.
A2: Yes. The process is straightforward, and users should already have an established mental
model.
A3: Yes. When logged in successfully, the user will be taken to a different screen. If login is
unsuccessful, the cause will be displayed to the user, such as wrong username password
combination, network error etc.
A3: No. The mental model will not be changed, and no new concepts will be added.
User Action 2: Invite 1 friend to a session of 1 week, with $5000 to start with
A1: Yes. The button to initiate the invitation is easy to find and the right way to invite a friend is a
common action in other common applications.
A2: Yes. The name of the inputs are labeled clearly and the procedure of doing this action is
intuitive enough for users to recognize.
A3: Yes. A message shows the invitation is successfully sent would display after finishing this
action.
A4: No. The process should match with the mental model of doing similar actions in other
common applications.
User Action 3: Search and find MSFT stock and buy 10 shares
A1: Yes. Users should be able to get the correct action via their existing mental model of trading
stock in real world.
A2: Yes. The process is straightforward, and users should already have an established the
corresponding mental model.
A3: Yes. When purchased successfully, the new stock will be added to a list. If action is
unsuccessful, the cause will be displayed to the user, such as insufficient fund, network error
etc.
A4: No. The mental model will not be changed, and no new concepts will be added.
User Action 4: Sell the 10 MSFT stock they just brought
A1: Yes. The action to sell is very similar to the buying action.
A2: Yes. The action is very simple and intuitive.
A3: Yes. A message shows the stock is successfully sold would display after finishing this
action.
A4: No. The mental model will not be changed, and no new concepts will be added.
User Action 5: Share the result of a completed session on Facebook
A1: Yes. Users should be able to get the correct action via their existing mental model of
sharing on Facebook, since this is a very commonly used feature on most modern social
networks.
A2: Yes. The process is straightforward, and users should already have an established mental
model.
A3: Yes. When content shared successfully, a message will be displayed. If anything went
wrong, the cause will be displayed to the user, such as network error etc.
A4: No. The mental model will not be changed, and no new concepts will be added.
1.3 Prototype Illustrations
To use this application, users need to log in with their accounts. They can create a new section
with the time period and initial amount of money, which are both set by the users. They have the
options of playing it alone or inviting some friends to join the section and compete with each
other. After a section starts, users can search for the stocks they are interested in and view all
the detailed information about the stocks. They can buy or sell shares of the stocks. Users are
allowed to have multiple sections at the same time. They are able to see their rankings in the
section, which are determined by the amount of money they own.
To demonstrate the redesigned UI, we have created a low-fidelity prototype (shown in Appendix
I).
Section 2: Plan User Evaluations
2.1 Evaluation Protocol
The purpose of conducting the experiment is to measure the system’s performance and
satisfaction of the users. The subject pool will consist of 10 users who have different
backgrounds. They differ in age, education background, cultural background, experience with
similar software etc.
We will first present the software to the users participating in the experiment and explain the
purpose of the experiment. After providing them a brief instruction, they will be asked to login
with their Facebook accounts and invite a friend to compete with them in a section that lasts one
week and starts with $5000. Lastly, the participants will be asked to complete a questionnaire so
that we can learn about their background and how satisfied they are with the user experience.
We will use time stamp in the logging file to measure the performance of the application and the
data will be collected for the analysis. The data we want to collect are the followings:
The time for users to register and login using Facebook
The time for users to invite 1 friend to a session of 1 week, with $5000 to start with.
The variables in this experiment will include:
Dependent variable: time spent on finishing the task
Independent variables: familiarity with Android applications, experience of playing similar
games
We have 2 options for the controlled experiment to choose from. We can either compare the
results of the experiment from 2 different designs or determine whether the single new design
meets the key design requirements. Since our time for this project is limited and we do not have
a significantly different alternative design, we have decided to use the second approach.
To make the result more realistic, we would not tell the test subjects that we are measuring the
time of them doing certain tasks. We will ask their permission to use such data after they have
completed all of the tasks. To analyse the result, we will use the Logcat in Android SDK. Logcat
is the Android logging system which provides a mechanism for collecting and viewing system
debug output. Logs from various applications and portions of the system are collected in a
series of circular buffers, which then can be viewed and filtered by the logcat command. The
Logcat allows us to timestamp user actions without interfering the user, and this will result in
more accurate result closer to real situations. The timing results would be accurate up to
microseconds.
Section 3: Tasks and Requirements
3.1 Subjects
Due to the constraint in time, we used ten representative users as subjects in our user study. To
protect their privacy, alias is used instead of their real names.
The following table shows the basic information of the 10 chosen subjects:
Alias Age Occupation Description
Wayne 31 Businessman His work involves trading stocks and he has experience of using different stock applications
Kyle 24 Waitress She has little knowledge of stocks trading.
Kent 28 Journalist He does some stocks trading occasionally and often uses a mobile app to obtain the information.
Diana 40 Housewife She is interested in stocks but not familiar with mobile apps.
Dick 22 Engineering Student He has no knowledge of stocks trading. He is familiar with mobile apps on different platforms.
Parker 22 Arts Student He is enthusiastic about stocks but he does not want to take the risk.
Stark 32 Mechanical Engineer He has little knowledge of stocks trading.
Grey 29 Professor He does some stocks trading occasionally and often uses a mobile app to obtain the information.
Logan 30 Coach He has no knowledge of stocks trading.
Kal-El 23 Science Student He has little knowledge of stocks trading. He is familiar with Android apps.
Since we did not involve any users in our Pass 1 design, all subjects in the Pass 2 user study is
new to this project. Since this is the first time they have seen the project, all subjects have the
same amount of knowledge of this app and thus the same starting point. However, other factors
may also affect subject’s performance in the experiment, such as user’s familiarity with
smartphones and mobile applications, or their experience in playing similar games.
3.2 Evaluation Results
In this project, there are 2 areas which may represent the quality of our design, the
usability/leanability of the overall system, and the user engagement in the game(aka amount of
fun). The most challenging part of the user study is to measure the user engagement
quantitatively.
We first conducted an experiment that evaluates the usability/learnability of our design.
As mentioned in section 1, the subject pool consists of 10 users who have different
backgrounds. They differ in age, education background, cultural background etc.
We first presented the software to the users participating in the experiment and explain the
purpose of the experiment. After providing them a brief instruction, they were asked to interact
with the system. Since we change our prototype platform from Android to proto.io, the
timestamps in the logging file is no longer available. As a result, we had to measure the times
manually using a timer. The results becomes less accurate than the results we planned to get
using Android LogCat.
The results are shown below:
0 10 20 30 40 50 60 70
Baseline
User 1
User 2
User 3
User 4
User 5
User 6
User 7
User 8
User 9
User 10
Time (s)
Use
rs
Start a Session with 3 friends
Time(s)
0 10 20 30 40 50 60
Baseline
User 1
User 2
User 3
User 4
User 5
User 6
User 7
User 8
User 9
User 10
Time (s)
Use
rsBuy 10 shares of MSFT Stock
Time(s)
0 5 10 15 20 25
Baseline
User 1
User 2
User 3
User 4
User 5
User 6
User 7
User 8
User 9
User 10
Time (s)
Use
rs
Check Stock Quote
Time(s)
Findings:
From the results we got from the user study, we can see that time from 3 different tasks are
related to each other. From the graphs, we can see that User 1,2,3 and 9 completed the tasks
relatively faster than other users in the subject pool. And looking back at their background
information, we can see they are experienced Android users, which are more familiar with
system conventions on the Android platform. On the other hand, User 10 used more time than
most of other users in all three tasks. Based on his background, we found out that User 10 is
not very familiar with most modern touch screen oriented mobile platforms, and this was the first
time he/she used Android platform.
Problems and Limitations:
The first problem of this evaluation is that the base-line of the study is difficult to find. Since the
concept of this game is relatively new, there are few other games and apps offer similar
experience. So it is difficult to compare the results with other games. And due to time constraint,
we did not have enough time to build an alternative design. As a result, we decided to use the
time result from the system designer (us) as the base-line.
Another limitation in this experiment is that subject group is too-small and insufficiently
representative. There are only 10 people in the subject group and they are not diverse enough
in terms of technical background.
Last but not least, the user study we carried out did not capture the user satisfaction or user
engagement when playing the game. Usability and learnability are important in any kind of
software application, but it is not the most crucial factor in a game. We planned an experiment
to measure user engagement when using the app, but unfortunately the prototype we
developed was not functional enough for the experiment. The planned experiment was giving
the subjects the highly functional prototype and let them play the game for 1 week. We would
then collect the data from the logging files to find out the total time they spent on the game,
single session play time (Time spent each time they open the game), and the frequency they
check the game on a daily basis. But the prototype we developed using proto.io prototying tool
did not have any dynamic data, and it was not able to support this experiment.
The tool we choose for this prototype is proto.io, and website designed specially for prototyping
mobile applications. However, we discovered that it do not suit the complexity required in our
project. By the time we discovered this, we have already invested a large amount of time on this
tool. Due to the time constraint, we did not have the opportunity to discard the tool and build the
prototype using a more suitable tool such as Flash or HTML.
3.3 Final Design Rationale & Discussion of the State of the
Design
The quality of the interface design meets the basic user expectation and we have
achieved our objective to make the interface simple to use. All the features included in
the interface are fully functional so that users have no problem doing any supported
tasks with the interface. Moreover, no complex operations are required for users to
complete those tasks. Overall, the users who have tried to use the interface are
satisfied by its look and feel, responsiveness and how intuitive it is.
One part of our design that works well is its simplicity and cleanness. The feedbacks
from those users suggests that the app is very clean and has a minimalistic approach
that displays much of the information that users require. In attempt to shorten the time
users need to spend on performing the tasks, we made all the screens well labeled and
the buttons easy to find with meaningful icons that represent their functionalities. We
think that this is the other aspect that works well in our design.
However, there are plenty of room for improvement on our design. Firstly, for users not
familiar with the financial market, the complex details of stocks in the user interface
becomes unnecessary and to some extent even confusing. There are some usability
issues mainly arising around the lack of system status updates or relying on users to
remember what features did without any indications on the part of the app. Some users
also suggests that the ability to rename the already created profile/game session could
be a welcomed feature. Help documentation is not included in the current session. This
is very important to include with any application. Inclusion of an FAQ can also clear up
the most common questions that users may have.
Aside from the usability problems, the user experience is another area that needs
improvement. Although the application functions as a game, the interface resembles the
ones from some other existing stock app. The application needs a more creative
interface that gives the look and feel of a game. Moreover, more interactions between
the users need to be supported in the design. For example, in the latest prototype,
users can easily view the status of their own portfolio in the current session, such as
their ranks among all users in the session, the total value etc.; however, users are not
able to see other user’s portfolio information, such as their friends’ owned stocks, ranks
and total value etc. This is one of the key features missing from the current prototype
since social functionality and interaction between users is one of the focus of this game.
The screenshots of the final prototype of this project is shown in Appendix II.
3.4 Reflection on the Design Process
Throughout the design period of the project, we have gained a better understanding of Human
Computer Interaction. The most important thing we have learned is that understanding the users
well can significantly save time and cost for re-work. It is obvious that the feedbacks from users
have great impact on how the design is changed.
In our project, we experienced a design overhaul where our objective got changed from creating
an application that displays stocks information to developing a game that simulates the real-life
stock exchange. Recognizing the target users and their actually needs are the main reasons
behind this big change. As we further interacted with some potential users, we found that there
were often certain elements of the design we did not recognized as issues, but they later
became some minor problems users had trouble with. One example is that revealing the
navigation menu hidden on the left of the screen was considered simple and intuitive by us, but
during the design evaluation, it took some time for a few users to figure out how to use it.
The medium/high fidelity prototype we created can help us to estimate how effective the user
interface is to make the game easy to control. However, demonstrating only the interface
without the back-end data and algorithm to make the game playable is not sufficient for
measuring how fun the game is to the users, which is an essential metric for a game. Although
no corresponding data could be collected in this project, given the limited time of the design
process, we believe that the prototyping method we used is the most suitable one for our
project. We must first ensure that the users are satisfied with the interface before proceeding to
the back-end implementations.
Among all the activities we have done for this project, we found creating the low fidelity
prototype the most valuable. Presenting the design ideas using paper prototyping method at the
beginning of the design process is rather effective for saving time and cost since it allows us to
get useful feedbacks before we start coding. Although, this type of prototype might look simple,
it contributes to capturing a considerably complete design of the interface. In addition, in the
early stage of the process, it is a good way to get every team member involved and to let them
express their ideas.
After learning Human Computer Interaction through the course material and the project, we
think the approach for our next interface design project would be very different from before. We
would no longer rush to start writing code; instead, we would attempt to interact more with
users. This way helps to identify the usability problems before the code is written, saving time
and cost and improving the overall quality of the software.
Section 4: Resource Management
The total time spent on Pass 2 of the project was longer than estimated. The following
tables show how much time was spent on doing the tasks for each person. (Note:
Project Demo Preparation includes the process of building the final prototype of the
project.)
Yawei Li
Task Spent Time (hrs)
Pass 2 Discussion 2
Pass 2 Evaluation Plan(s) 4
Project Presentation Preparation 3
Project Demo Preparation 7
Pass 2 User Evaluations 3
Pass 2 Report 6
25
Nenghao Lin
Task Spent Time (hrs)
Pass 2 Discussion 2
Pass 2 Rational 3
Project Presentation Preparation 3
Project Demo Preparation 7
Pass 2 User Evaluations 3
Pass 2 Report 6
24
Tommy Wan
Task Spent Time (hrs)
Pass 2 Discussion 2
Pass 2 Prototype(s) 4
Project Presentation Preparation 3
Project Demo Preparation 7
Pass 2 User Evaluations 3
Pass 2 Report 5
24
The total amount of time our team have spent on Pass 2 is: 73 hours.
Appendix I: Low-fidelity Prototype
Login Screen
The first time users launch this app, the login screen is displayed. Users can either
login if they have an account or sign up for a new account.
Home Screen
After logged in, the user will see the home screen. The most recent portfolio the
user has viewed is shown with the information about this portfolio and a list of
the stocks bought in this portfolio.
Detailed View
When one of the stocks on the home screen is pressed, the detailed view will
show up. It contains the important information about a stock such as graph range
etc. The number of shared the user owns is shown at the bottom and the user can
buy or sell the shares.
Navigation Menu
The names and status of the portfolios are shown in the navigation menu. The
user can switch to different portfolios by pressing on one of them. The user can
also start a session by pressing the button at the bottom.
Appendix II: Medium-fidelity Prototype
Login Screen
The first time users launch this app, the login screen is displayed. Users can either
login if they have an account or sign up for a new account.
Home Screen
After logged in, the user will see the home screen. The most recent portfolio the
user has viewed is shown with the information about this portfolio and a list of
the stocks bought in this portfolio.
Home Screen (with Navigation Menus shown)
The names and status of the portfolios are shown in the navigation menu. The
user can switch to different portfolios by pressing on one of them. The user can
also start a session by pressing the button at the bottom.
New Session Screen
After the user press the “Start A New Session” button, he/she will be navigated to
the New Session screen. Some information needs to be filled out before the
session can be created.
Search Result Screen
After the user inputs the stock he/she want to search for and press “OK”, he/she
will be navigated to the Search Result screen.
Detailed View
When one of the stocks on the home screen is pressed, the detailed view will
show up. It contains the important information about a stock such as graph range
etc. The number of shared the user owns is shown at the bottom and the user can
buy or sell the shares.