Coursera Capstone Project: onTime

Sometime back, I took University of California, San Diego’s Interaction Design Specialisation on Coursera. Part of the specialisation involved creating a final ‘capstone’ project, which involved following the entire process of designing an application.

My Design Brief was based on Time
The design brief concluded with an interesting question: “With the computation and sensing capabilities of mobile devices, can we find a more personal and joyful way to interact with time?”

This lead me to think about the numerous calculations and combinations we end up applying when we need to reach a place on time, and are somehow getting late. “What if I took the train from the slightly farther station but skipped the connecting train that’ll have to other wise take?” “What if I covered the entire trip by car?” “Which option should I pick to reach my university on time?” . Why should we have to calculate these times? Why can’t our phones recommend us the fastest way, Doing the heavy lifting for us.

I started my project by observing and talking to people about the process they follow to reach on time.

What was being observed?
1. What is the preparation that people do to get from one place to another.

2. What goes into their minds before they start their trip?

3. Do they use a combination of transport to reach their destination?

4. Observe the process of booking a ticket / booking a uber / getting into the bus. What are the steps involved?

4. What are the different apps that are used in the process?

5. Is there a ticketing process which can be unified?

6. How do the people estimate their time of arrival?

7. If public transport ? then are the timings reliable.

Ultimately, I could solve only a few of the problems that the users would face in their daily commute, by this app. But it was important to get a broad spectrum of what people did when they had to reach on time.

Observations and Interviews were recorded in Different Personas.

Since I was travelling at the time of the interviews, I was lucky to get a different perspective of how people travelled the world over. All three subjects leading to interesting design opportunities.

Initial Design notes from the observations made.

Brainstorming

Eventually I landed to one Point Of View Based on the Design:

Point Of View: Reaching in time shouldn’t be hampered by a poor transit choice.

Design Brief: Time
People generally need to be at a certain place, within a certain span of time & have different transit options to choose from. A bus, a train, rapid transit, an uber or even at foot. It’s important to pick the best possible solution to reach the place in time. While this is an activity that’s about moving between places, there’s a lot of time to be managed here & hence a lot of interaction with time.

Storyboarding

Late to a party, Mudit needs the fastest way to reach there.

David woke up late and needs to reach his office. What should he do now?

Two Prototypes Emerged

Two prototypes emerged after all the needfinding and ideation was done. While one focused on the place you want to be at, the other focused on the route you should take. Initial Sketches

Initial Sketches and Workflow

Prototype 1 :The focus was on the route

Prototype 2: The focus was on the “Place”

Peer and Heuristic Evaluations

Laid out o a the desk, these cards were ready to be evaluated by my brother!

The first evaluation I conducted was with my brother, whom I showed the two prototypes watching him navigate through the screens! His reactions served for the basis of the initial Heuristic Evaluations for these prototypes, which would eventually decide what goes into the app.

The setting needs to be right! The Peer Evaluations were conducted on a makeshift iPhone! :)

Time for Evaluations

A summarisation of the walkthroughs done with family members and fellow capstone project peers (using TalkAbout Time), these Heuristic Evaluations served for the basis of the final working prototypes which would further be tested out with other people!

Evaluations for the two prototypes

Summary of the Evaluations:

From the Heuristic Evaluation made by my brother and peers it is evident that in Prototype 1, There are major usability issues over Search Suggestions. Users found them to be too few and wished for greater flexibility in that feature. Users also found the use of gesture for diving into the detailed view for a route to be non-intuitive and something that could be confused with the system gestures. Concluding, The Prototype 1 which focuses on the route, faces issues over the customisability of the suggestions and the lack of information about the place. There are a few possible solutions to the problem, the problem of flexibility can be fixed with a) User Profiles, b) An Option to set a place above the search menu c) an option to access more than just three places.

Gestures could be fixed by use of a slightly different metaphor for the detail view. (for example a simple tap). This would solve a few visibility issues as well.

The Prototype 2 which focuses on the Place a person wishes to go to was much better received than prototype 1 but needs iron out a few kinks too. For starters, the filter option is confusing as it fails to tell the user how to use it for searches. This could be fixed by adding the filter option to a more central location instead of at the side of suggestions. There seems to a be confusion over the fastest and the best possible route. Clearly this needs to be more proactive or more clear. There could be A couple of ways to fix this a) To not show any route until the time is decided, sorting the routes on the basis of time, once it is entered b) making the difference between fastest and best route more significant.

Concluding : Prototype 2 was better received by the evaluators. However, the need to customise more was also present. There was also a desire to have a look at the users current location instead of just the destination. Taking all points into account, I guess going ahead with prototype 2 would be a better decision, while some of the positives from prototype 1 could be transferred too.

Walkthroughs for Hi Fidelity Prototypes!

With the changes from the Heuristic Evaluations, the time had come to create high-fidelity mockups of the prototypes, ready to be test in the outside world!

More designs, More Walkthroughs and More Iterations. This is the stage where the designs were going to be put under intense scrutiny.

Some Notes from the walkthroughs:

A lot of changes made from the observations on the walkthroughs. But I was particularly keen on getting a wider opinion on one particular feature of the app.

There wasn’t a clear consensus on whether the my new approach was going to be better or not. An AB test was needed!

A/B Tests

For my A/B Tests I picked up an important aspect of the app. I drew two alternatives on Sketch. Duplicated my online prototype and using an online User Tests portal (by the name of UserTesting[dot]com. Two Prototypes were going to be checked for on the basis of speed. Further more, an independent Samples t-Test and Chi-Squared Analysis was going to be conducted.

Two alternatives to the workflow of finding the best route.

These prototypes were then fed into the hands of Independent testers from UserTesting[dot]com who then put them under professional scrutiny. The tests not only provided me with important data to conduct my User Tests they also had some suggestions on how I can Improve the app!

Conducting Tests from the Given Data

The following Data was collected from the Samples:

The indications were clear, Prototype B was much faster. But what do the User tests finally say?

While the Ch-Squared test positively challenged the null hypothesis, the Independent Samples t-Test indicated a difference but one that wasn’t significant enough.

Ultimately the Prototype B was chosen for the final fit and finish. Along with the changes that were suggested by the testers and evaluators!

To sum it up, Interaction Design largely boils down to a circle of iterative design that must be followed in order to make delightful user experiences.

The last leg: Fit and Finish!

After multiple iterations, fixes and Evaluations, it was time to give a final coat of polish to the product! Following the right grids, picking up the right colours and nailing down the animations! It’s time to show what the prototype!

Here’s Presenting onTime: Never be late again!