2013-14 Term 1 G2 SIXDOTZ

From Interaction Design and Prototyping
Jump to: navigation, search
Home Assignments G1 G2 Technology


Assignment Deliverables Self Assessment Comparison to other Teams
A3. Low-fidelity Prototype Deliverables DateTime: 12 Sept 2013 1.30pm

The problem and solution is done based on the requirements that our IS480 sponsor communicated to us, where we selected the more interesting pair out of all the requirements. Personas are clearly thought through with specific details on their background, CCAs, aspirations and interests that will likely affect the kind of events that they will create with our app. Our Scenarios shows a typical situation where users decides to use our app to solve their needs, we also included a more difficult scenario when users could not find the event that he/she wants. Our flow diagram are clearly designed to match the scenarios depicted. Lastly we feel that our paper prototype clearly display how our exact UI would look like and enable a user to experience how it is like to fiddle on the real application.

13 Sept 2013 11:30am:

Team 4 Bill Splitter

We like the idea that the team drew out the scenario in a storyboard form. It is more interesting than just reading paragraphs of scenarios. The video for the prototyping is nicely done. We could easily understand how the application works by looking at the video.

A4. Heuristic Evaluation (End of Iteration 1)

Deliverables 19 Sept 2013 @ 11:20AM
  • Did a full walk through of the application with all the evaluators as if the application was a live deployment.
  • Problems listed out have been clearly described and categorized according to their severity category. Such a categorization would thus enable us to prioritize the changes required for future iterations of the prototype.
  • Solutions were provided for all problems identified
19 Sept 2013 @ 3.20pm:

The Eagles: SoCAL

The team did a detailed breakdown of problems identified by each evaluators. The team also did a pie chart of the distribution of severity of problems.

We feel that this analysis of severity ratings will be helpful to the team as they can have a clearer view of the problems they had with their paper prototype.

The team also grouped the problems identified by its severity ratings which allows for easy reference to the more important problems first. They have also counted the number of problems within each severity rating category.

A5. High-fidelity Prototype 1: A Skeleton and a Plan Deliverables 26 Sept 2013, 11:57 am
  • Screenshots for all major views in the flow diagram are present and clearly shown.
  • Scenarios and flow diagram is detailed, in a logical flow and is consistent with each other.
  • Work items on implementation plan is very concrete and easily detectable on the UI.
  • Changes made to prototype is clear with photos and large captions as visual aids.
30 Sep 2013 4.50pm

Team 4 Bill Splitter

  1. Prototype - It's clear in their screen shot the sequence of events as we move from screenshots to screenshots.
  2. Scenario - Their scenario has a storyboard with pictures to understand what the scenario is about. It beats reading sentences of words.
  3. Plan - They have very detailed plan of which team member is in charge of which task, all the way until Week 13.
  4. Change - Their change picture are very interesting as they have combined several photos into one, which will change every few seconds. This is very interesting and save the hassle for the person viewing to open too many photos.
A6. High-fidelity Prototype 2: Meat on the Bones Deliverables 3 Oct 2013, 10:18 am
  • Provided the updated runnable of our prototype and screen shots for all major views. All views are consistent with the flow diagram.
  • Implementation plan is realistic and caters to the schedules of all team members. Flow diagram was updated accordingly.
  • Necessary changes made to the plan were clearly justified.
  • We have accomplished all tasks that were allocated in Week 7 on time.
3 Oct 2013 10:22 AM:

Team 3 ING Bank's Procurement Workflow Management System

The team only had one flow diagram which makes it easier to understand compared to two flow diagrams of our's. The team also had their scenario in point form which aids reading. The team has prototype running and also screenshots were taken.
A7. High-fidelity Prototype 3: Ready for Testing Deliverables 26 October 2013, 12:40 pm:
  • Our prototype are functional and running on a development server for stability.
  • We have updated the scenario, flow diagram and implementation plan
  • We completed the tasks to date and follow the implementation plan closely.
  • We also summarized the changes to our prototype.

We should have included before and after photos of the application that we have changed.

Team 4 Bill Splitter DateTime: 26 October 2013

Evaluated team's number and project name

The team kept a bug matric table and bug matric log to track the quality of their application. Thus with this, they are able to keep a good track to ensure the prototype built will be stable.
A8. Laboratory Test

(End of Iteration 2)

Deliverables 27 October 2013, 10:13 pm:
  • Goals and purpose were clearly defined and covers all the major functions that we want to test out.
  • Each task is a complete process and specially designed so that our team is able to observe users behavior and reaction. After each task, we interviewed the user to get feedback. This allows us to collect comprehensive data for improvement.
  • From the data collected, we managed to find some common concerns and opinions among users and a few interesting takeaways. Hence, we can then improve our design and cater better to the needs of residents.
  • As a team, we ran through all the comments gathered and decided on which ones we felt essential. For all changes to our prototype, we included before and after screenshots, explained in detail what users' concerns/feedback were and the changes implemented.
  • All test documents are detailed and easy to follow.
  • Our team felt that we could have done a better job in making sure the application was bug-free before conducting the pilot user testing.
27 October 2013, 10:05PM

Team 1 Mobile Bus Charter Service

The team categorized the problems that the testers found during test into different categories, mainly basic comestic issues, complex comestic issues and functionality issues. By categorizing the problems found, it is easier for the team to identify different task that needs to be rectified and prioritize what needs to corrected. Our team like this method of doing things as it helps the to save time when doing changes to the prototype.
A9. Web Experiment 1: Setup Deliverables 3 Nov 2013, 9:52 PM:
  • Our changes to prototype are cleared illustrated and justified
  • Experiment can be found on the web.
  • Informed consent form appears at the first page of the experiment.
  • Our experiment has detailed walk-through.
16 Nov 2013, 3:40PM:

Team 7, LateLiao

Their changes to prototype has more details and reason to why they made the change. And also they clearly define which function they are explaining when going through their prototype page.They also clearly define what are the goals of the web test and what variables that they will be using.
A10. Web Experiment 2: Analysis Deliverables 16 Nov 2013, 1:50PM :
  • We recruited 32 participants who are real users of the future application
  • P-value calculated from the results are analyzed
  • We made our conclusion based on clear result that the response time of the two column layout is 25% faster than the one column layout
  • Explanations were included to support the validity of our conclusion
  • Changes to prototype is clearly illustrated with pictures.
17th November 2013, 8:05PM

Team 10 Diversity

The team explained the hypothesis and results clearly, including pictures of their test.

Limitations of their test were also stated.

A11. Poster Session (End of Iteration 3)

Deliverables 16 Nov 2013, 2:00PM :
  • Our video clearly shows the pain point of hostel residents, the features of our application and how our application can help to solve the problem. The main actor was an existing hostel resident and we included appropriate effects and words to help our audience relate to the message of our video.
  • For the poster, we have stated clearly the main problem faced by hostel residents and the solution. The evolution of our prototype was shown in iterations. In each iteration, we explained the major changes implemented based on the user tests that we conducted. We also included pictures of our prototype and the user tests. Design wise, we incorporated what we learnt during the course e.g. colors, fonts to create an appealing poster.
  • Our prototype is fully functional and incorporates all the scenarios. From the paper prototype till date, the prototype has gone through major User Interface changes based on the feedback we received. We felt that it has indeed improved visually and become more user-friendly.
  • During the poster session, we took down all the feedback given by the judges. This would be very helpful as we continue our development for our Final Year Project.
17th November 2013, 8:08PM

Team 4 Bill Splitter

For their video, we liked the story concept and the use of

interesting characters and icons. Their poster is visually appealing and it is very easy to follow the journey the group went through.


Team Name SixDotz
Project Name Prinsep Community Life Portal
Design Brief SMU Prinsep Hostel - Prinsep Integrated Portal
Problem It is difficult to connect with everyone else at the hostel, specifically residents find it hard to engage other like-minded individuals to join informal events that they organise.
Solution To have a web application that allows residents to create informal events, and also to view and join other events that other residents created.

G2 Deliverables

Iteration 1 A2 Observations
A3 Personas
Scenarios A3 A5
A3 Alternative Designs
A3 Paper Prototype
Flow Diagram A3 A5
A4 Heuristic Evaluation
Iteration 2 A5 Implementation Plan
A8 Lab Test
Iteration 3 A9 Web Experiment Setup
A10 Web Experiment Analysis
A11 Poster
A11 Video

High-fidelity Prototypes

Runnable 1 Name <Main App>
Type <Stand-alone application>
Platform <Android 4.0.3 on Samsung Galaxy SII>
Toolkits/Frameworks Used <Android SDK r22>
Major Releases Iteration 2, Iteration 3
GitHub repository
Runnable 2 Name <Admin App>
Type <Web application (Chrome)>
Platform <Microsoft Windows 7>
Toolkits/Frameworks Used <jQuery v1.10.2, jQueryUI v1.10.3>
Major Releases Iteration 2, Iteration 3
GitHub repository