Fast Facts

initial screen of the application
home screen of the application
  • Role:
  • UX Designer
  • Project Type:
  • Android Application
  • Dates:
  • September 2016 - December 2016
  • Team Size: 5

Tools:
  • Pencil and Paper
  • Photoshop CC
  • Balsamiq
  • Android Studio
  • Microsoft Excel
Skills:
  • Interviewing
  • User Archetype Development
  • Need Finding
  • Task analysis
  • Iteration Process
  • Working within a multidisciplinary team

The Challenge

Finding social and professional events as a student is a difficult process when you factor in other obligations such as tests, meetings and study time. By having a tool that factors the search for events and your unique obligations and filters is missing. The drive for this project was to create an application that combats the fear of missing out while still being studious.

Exisiting Solutions

Through our effort to research current solutions we found that they were lacking in certain areas that didn't solve our problem. We also analyzed the strengths and weakness of current solutions so we can learn from them in terms of functionality and usability and possibily incorporate them in our project

www.facebook.com/events

This was the main inspiration to create an application based on events. At that time, we found that facebook events did a very good job on having a central area for events but it did not incorporate other calendar features into their system.

www.meetup.com

Although a great site that allows users to create groups for certain interests (hiking, cycling, etc). We found that it lacked a user's availability features to show the system when users are free.

Proposed Solution

We have introduced an application that brings exciting events directly to the user’s hands. We wanted the user experience to be fluid and easy to use. We also wanted the user to have the ability of choice. The events would be based on their availability and interests.

YOUR CALENDAR + YOUR INTERESTS = LOCAL EVENTS YOU CAN AND WANT TO ATTEND

Wire frames

initial wireframes
final wireframes

Testing

I lead the team in creating the standard procedure for testing. This method allowed the rest of the team to test and interview users with ease and haste. Prior to testing, we sampled potential users and developed the User Archetypes you can see below. Each testing sessions, I went through a sequence of methods and questions regarding the prototypes.

User Archetypes


Sami: “ONLY WHAT’S NECESSARY”

  • Talked about important events that are relevant to the user. These included interviews, meetings, deadlines, and other important obligations.

  • Personal things such as sitting down to do Homework and cleaning the house were left to “eye-ball” and was meant to be very flexible in terms organization.

  • The user would search online through facebook and their University's website to find events that they would be interested in.


Brandon: “RESPONDS TO STIMULI”

  • The user sets alarms for predetermined obligations, like classes or group meetings, but will occasionally add an alarm for additional events.

  • These events are sourced from his emails, which include campus-wide updates, engineering RSO event reminders, and engineering networking opportunities.

  • The user finds that they generally attend events that alert them on the day that they occur.


George: “I’LL KEEP IT IN MY HEAD”

  • Discussed how they did not utilize a calendar to plan out a schedule for the day. Instead, assignments and meetings are kept “in their head”.

  • When looking for events to do in their free time, they would briefly search around on Facebook, talk to friends, or just stay at home. They were very flexible in scheduling their day.

  • They would be willing to use the app to look for events they would want to attend or are interested in.

Proposed Tasks

  1. View and edit the application's generated calendar to reflect plans.
  2. Votes to coordinate group activities with other users.
  3. Look up events that fill empty (negative) spaces in the user's calendar.
  4. Look up events that fill user-defined free-time (positive) blocks in the user's calendar.
  5. Export capabilities of the calendar generated by the app to their regular calendar service.
  6. Ability to find out what other users are attending via a third-party service like facebook.

User Testing

Methods

  • Investigating how the user perceives the app and how well it meets our goals by having the users talk aloud while navigating the app
  • Acting as "a fly on the wall" with each participant. Used to observe a naturalistic use of the application. Answer all questions after each testing process

QUESTIONS USED

  1. How does this transition process feel?
  2. What are some weaknesses of these processes?
  3. Asked for general weaknesses and then narrowed them down by asking more specific questions
  4. What are some strengths of these processes?
  5. Asked for general strengths and then narrowed them down by asking more specific questions
  6. Questioned if the user would use this app, how often, and why.

Final Screens

Screenshots done with balsamiq and photoshop
final screenshots on an LG G4 with Android 6.0

Summary and Reflection

In summary, My team and I created an application that shows events curated on availability and the user's interests. We did this by investigating potential users and their needs and wants. We discovered that our users want things done quick, easy and well. Our users indicated that they wanted to be notififed of new events in their area. Through the process of design thinking, we were able to rapidly iterate on our designs to create a ready to ship product.


Difficulties Faced

Some difficulties we faced were time constraints from the project. Since this was a course project, we only had about 2 weeks to develop the application, reiterate and present. On top of these duties, we were all still full time students therefore had other obligations that sometimes were more pressing. This is where I had a difficult time in understanding my team's strengths and weaknesses in pushing changes to the application. The final difficulty we had was narrowing down what our users thought to be interesting and what exactly they wanted. Interviews and questionnaires can only answer so much, therefore attending to all the issues was a challenge. With all these difficulties we had faced, we ultimately had to cut out certain features that we physically couldn't create in the alloted time.


Lessons Learned

Finally, my team and I learned a lot from this project. We learned that iteration is key in good design. We also learned that good ideas come later during the ideation phase. The biggest thing we learned though is about teamwork and working together. Finally, I would like to mention that our teamwork on this project highlighted everyone's strengths and improved everyone's weaknesses. I learned how to be a better leader and organizaing details on the project team. I had also learned that if a percentage of the team isn't pulling their own weight, it becomes very difficult for the rest of the team to move forward.