Reflection on CS 449 UWaterloo
For my 3B term at UW I decided to take Human-Computer Interaction as one of my Computer Science electives. I had heard a lot of mixed reviews in the past so I wasn’t sure how I would find it, but given my growing interest in product management, I decided I would give it a shot. I have to say I am surprised at how much I have been enjoying the course.
The structure of the course, when taught under our professor, Edith Law, is very different than many other CS courses. We didn’t have a midterm nor a final, and there was no coding involved. It’s a fully project-based course, which focuses on team collaboration and organization, paired with insightful lectures and very interesting reading material. I really enjoyed the course because it filled the gap of applicable industry knowledge that other CS courses often don’t provide. We had the chance to shift our focus from the algorithms that run an application to the product that the application aims to be.
Edith would usually spend the first half of classes teaching new material, and give the students the second half to apply those concepts while building the next part of our project. This dynamic allowed us to keep our attention and interest high, which eventually resulted in higher productivity when we had to get to work. Our project was divided into deliverables, which were graded weekly and consisted of group work, which was either inside or outside the classroom environment. Some examples include conducting user interviews to verify our assumptions, building paper prototypes to get an idea of how the app should look like, presenting our results to the classroom and conducting in-class user testing with other groups.
All the activities were very engaging and simulated real-world problems, which made them so much more interesting. Here is a link to our course homepage, containing all of the information regarding how our term was structured.
Project Goal
The problem that my team and I were set to solve was to enable a community to set and achieve goals. We chose our topic as we believed that there wasn’t any good service that helped tackle this issue at a community, rather than at an individual, level. Given this niche, it was an interesting proposition for us to work with and to try to solve. Our intention to tackle this problem was to build a smartphone application to connect organizers with participants in order to promote the completion of community tasks and goals.
The market segment we set to target ranges from high school students to seniors. We believed that anyone with a smartphone could access the app and that, consequently, they would also be interested enough in their own community. This includes a large age variety, which can be reflected in the possibility to have different kinds of community goals that can be set and contributed to.
Allowing communities to set goals for their members to complete over a period of time can offer a variety of contributions such as a greater bonding between people; giving the feeling of doing something that is good for others; improving the environment where one lives in. These outcomes then add value to the area as outside members will look up to a community that prioritizes group work and social activities.
During our work, we decided to focus on a few sets of problems: how to enable our users to view events they could attend, including a way to filter results and display them in different views; how to motivate users to participate in these challenges, thinking about gamification and psychological strategies; how to collect data from the outcomes of the events, in forms of potential surveys or other user responses. We decided that these problems were the most important to tackle in order to produce an MVP and that other applications of our solution could then be added to successive iterations.
Anticipated Users
One of the first activities we worked on, following the problem assessment, was to define our users and create empathy mappings and user personas. We came up with five different user groups and relative personas that we believed encompassed the types of users we would receive.
- Community Driven Individuals: Individuals who want to be actively involved in community events. This category includes individuals who want to do good and feel like the world can be improved. They might be influenced by friends and active family members in the community. These people may worry about the time commitment, failure of task/event among others. The persona development has allowed us to imagine Kevin, a high school student looking for volunteering opportunities and socializing. He would be really interested in tracking his participation to use it towards scholarships and university applications. He is worried about the time commitment and the awareness of events.
- Reclusive Individuals: Individuals who may not necessarily be concerned with community events around them. They may have different reasons to avoid participation such as being too tired after class/work, being shy, lacking familiarity and knowledge about events, or just preferring to stay at home or do some other plans. John, the persona developed, is a middle-class adult with a 9 to 5 job with free time in the evening looking for activities to do. He would like to see things fixed in the community.
- Business Owners/City Planners: Businesses or organizations that would be likely to host large scale, frequent community events. We believe these will worry about their business and the city they are in and will try to organize community events. They would need to calculate if the rewards are worth the costs. For example, they may consider joining if competitors are joining, for business opportunities, to obtain a reputation, or to improve their business and city. The persona development has led us to create Tristen Beyer, who is a Marketing Analyst / Event Planner focused on finding business opportunities, increase the company’s profits and raise business awareness. His fears are venue availability, business, and individual reputation and incurred costs.
- Elderly / Disabled Individuals: The primary focus would be maximizing accessibility and availability to these users, and identifying current pitfalls and shortcomings of existing solutions that are causing members of these groups to be unfairly restricted from participating. These groups may worry about app usability. However, it can be very helpful for them to receive help and socialize. Karen Devis, the result of the persona development, is a 70-year-old woman living alone and looking to socialize and probably get some maintenance help. She is not used to the idea of having strangers helping her at home and does not know how to use complex apps.
- Individual Event / Task Aggregators: Local community members who identify an issue in the community they would like to see resolved, they would like to host an event to address a problem. The Persona development has led to Emmanuel Rico, a high school teacher looking to make a difference while having time to spend with family. He is an extrovert, perceiving, with intuition and feeling.
User Interviews
An essential step of creating a product consists of getting to know the people which the product is for. For our project, we had to conduct several user interviews to get real-world data, which was then used to prove or disprove our initial assumptions.
Overall we interviewed five potential users. Of those five, three were university students, one was a university event organizer and the fifth was a business owner. Three of which were male and two female. Two of the students were participants to events, of which one was also an international student.
Before conducting our interviews we prepared a set of questions that we believed encompassed all aspects of community involvement that were relevant for our study. We also had different questions tailored specifically to participants and organizers, so that we could get more insight into their specific position during their role. We made sure we always asked open-ended questions so that we could leave space for our interviewees to give us as much information as possible, without making them feel restricted.
After the interviews, we would at times also make affinity diagrams to be able to efficiently visualize our results. For example, the affinity diagram we constructed based on the results from interviewing UW Health and Wellness Committee Member reinforced our assumptions with respect to availability, accessibility and reach of awareness in order to maximize participation in organized activities, as well as the need to integrate with services such as social media platforms as a direct means to achieve such reachability and awareness goals. It also confirmed our rationale to try and incorporate analytical features, such as the ability to collect feedback in the form of either surveys (i.e., collecting both quantifiable and qualitative responses), as well as more long-form, open-ended feedback to improve future activities.
These metrics are vital to activity coordinators in order to gauge the success of their activities, and identify any negative aspects experienced by participants in order to improve in the future. A potential hurdle that was brought to our attention was the inevitable truth that only a subset of users who indicated interest in participating in activities actually show up. An idea that was presented to us that falls within the scope of our incentive-driven approach to help participants realize the impact of their involvement, no matter how small it may appear to them. Thus, having been able to identify this as an issue with not only reaching people, but also the success of the event, it is definitely an area that requires careful thought in order to maximize the usefulness of the application from the point of view of an event coordinator.
From our other interviews, we gained insight on some of the reasons for which participants are more inclined to attend events, such as the opportunity to meet new people, spending some time with their friends, learning about a topic of interest or the chance to win prizes or get free swag and food. Other organizers instead shined some light on some of the difficulties they encountered while planning events, including the lack of responses received from social media or posters which contributed to low attendance during the event.
Another key tool that we used in parallel with our user interviews was work models. These are models that represent how various entities involved with our solution interact with each other, under various aspects.
In the Cultural Work Model, we established several key breakdowns. They dealt with handicapped individuals, reclusive individuals, between community involved individuals and event coordinators, and between event/task coordinators and reclusive individuals. To delve more into one, the interaction between the elder generation and task/event coordinators turned out to be very useful to analyze.
Communication both ways is challenged as technology isn’t a strong channel for older folk. Based on interviews, our general assumption was that elders may not be as experienced with technology and thus are not capable or motivated to navigate online to find local events to attend. Similarly, event coordinators don’t have an established communication channel to notify these individuals of nearby events. We hoped to address this with a notification feature, essentially allowing event coordinators to blast nearby events to a mobile device without having that individual open the app. This would remove the need for an individual to navigate the app to search for an event as the events would then be “searching for you”, directly addressing this discrepancy between elders and event coordinators.
In terms of central themes from the Flow Work Model, we identified three overarching candidates. The first was the ability for event coordinators and affiliated individuals (i.e., supervisors) to quantify and qualify the success of events. Specifically, this section of the flow model deals with the creation and distribution of surveys to attendees, as well as the creation, processing and analyzing of reports to iterate upon their own internal planning and coordination processes to improve events. The second theme we identified was that of event planning and coordination. This section dealt with the workflow associated with organizing event date(s), time(s) and location(s), which includes the negotiation process with venue providers and addressing breakdowns caused by venue unavailability (e.g., rescheduling). Furthermore, this section covered the planning of event activities themselves, as the vendor provider may have certain terms and conditions with respect to the usage of their venue that the event must adhere to. Lastly, we identified event propagation and marketing as a general theme from the model. The onus is on the event coordinator to somehow broadcast the event details, thus making its existence known to notify targeted and general participants. The need for such propagation is obvious, as the success of the event hinges on attendance, so the more tools at the disposal of the event coordinator to publicly notify potential attendees the greater the chance that the event will be successful.
From the Flow Work Model, we determined three potential new features to incorporate into the application. First, there appeared as though the means by which event coordinators and venue providers communicate could be augmented by the application. In particular, to provide direct means of communications (i.e., instant messaging) between these two parties, or perhaps a method where event coordinators could post something akin to wanted ads for a venue during a particular date and timespan, and allow venue owners to respond to such postings. The second feature we foresaw to be beneficial was the provisioning of views for supervisors to review and provide feedback on reports generated by event coordinators, thereby encapsulating the full reporting process workflow. Lastly, to add the necessary social media integration services for event coordinators to market and advertise their events.
Overall, we decided to focus on attracting users by giving them a very low barrier to entry. We believed that an easy to use interface to find events, combined with the ability to see how many other friends are interested and a points system to reward completed events would motivate users to look for community events to attend. Therefore our efforts have principally been spent on creating an intuitive and simple UI for all demographics.
Initial Design Ideas
Once we collected the first batch of information we needed, our next step in the product design process was to actually come up with some features that could address the problems we had been exposed to and create the first associated designs. Coming up with user stories turned out to be very beneficial and decisive in converging in a subset of features that we all agreed to be essential. The process included each one of us to come up with as many needs and wants that potential users may have, and then rank each other’s stories based on the relevance when compared to the results of our interviews.
We ended up choosing the top four needs that best represented the responses of our interviewees, and with those, we constructed a storyboard for each scenario. This activity was useful by giving us an idea of a scene that would create the need for our user to want to use our product and then going ahead and solving that need by using our app. Thanks to this process our first set of features included:
- creating events and allowing users to post comments and pictures about them
- finding and filtering events
- using surveys and polls after events to gather data
- including tags for events to better describe them
With our first set of features in mind, we set out to build our paper prototype and then connect it with a wireflow diagram.
Evaluation
For our next step of the design process, we had to build a first paper prototype and then have it tested by our peers. This was an in-class activity and it gave us a lot of useful insight into how our initial iteration was perceived by our testers as well as an opportunity to improve our existing features.
Our goal with the paper prototypes was to quickly provide illustrations of core components of our application (i.e., event navigation, registration and filtering, user profile configuration and progress indicators, and interaction with ‘friends’ within the application) along with some bare-bones functionality. We wanted interactive components such as buttons or menu options to be physically layered on top of one another to produce final composite prototypes. Thus, we realized immediately that we would have to have modular realizations of these components (i.e., separate cutouts), and make them pop-out. This way, when demoing these prototypes, it would be obvious to the user which parts are meant to be interacted width due to extrusion from the main template. We also utilized colored paper in some situations to indicate highlights within the application, serving as visual indicators as to its state, as well as act as a frame of reference for users.
A challenge with this activity was identifying concise ways to represent digital artifacts using pencil and paper. For example, mobile devices utilize value spinners or dropdowns when a finite set of options are available (e.g., for valid date and month selection). Thus, an accordion-style paper pop-out was created to simulate such functionality. The idea being that to fake response to user input, these pop-outs would be unfolded when the user ‘tapped’ on the appropriate field, to show the finite set of options. In addition to this, other cutouts, such as those for example tags that a user might input, were also stacked upon to the interface to simulate the envisioned digital product. In general, this exercise was challenging in that in lieu of well-established interface components on mobile platforms, we had to sketch them out, and try to be as clear as possible as to the intent and desired functionality of these components.
Upon performing the paper prototype evaluation we were able to gain insight into the usability of our product as well as better gauge which features were perceived as more valuable than others. Starting at our home page we originally presented three potential interfaces for viewing upcoming events in the user’s feed, a default list view just as you would see on an application like Kijiji, a map view and a calendar view. Right off the bat, our test user identified how they were satisfied with the default view and found it appealing and easy to use. They revealed that they likely would have no reason to use any of the other views, with the exception of maybe the map view. From this, we realized that the calendar view is not at all necessary and is something we could remove from our original design of the product. Furthermore, our ability to add events to a user’s native or default calendar app augmented this feature from the perspective of individual users. Secondly, our user focused on the actual interface for switching between this view. Instead of clicking on a menu and selecting a desired view, the two views could be alternated by swiping left or right on the whole view, similar to how Snapchat’s interface works. Due to the familiarity of that feature, our tester indicated that such a feature in our product would be a perceived affordance, and upon reflection, appears to be a more natural way to switch between views as opposed to our current design.
One of the features we specifically created a paper product evaluation for was the “Users” page, and through the evaluation, we were able to gain valuable feedback that we will consider in our redesign. Firstly, it was not intuitively clear to the user that the User’s page was scrollable, so adding a scroll bar is a must. Additionally, in terms of editing the profile, the user perceived that the edit button (placed underneath the profile photo) was specifically meant to edit the profile photo, so he suggested we placed it in a more generic location to indicate the edit button would be used to introduce a new page to edit all fields at once. Perhaps the most useful information for this portion was the observation of the user thought processes with respect to the order of sections presented. Originally, we had “achievements” over “my events”, and the user indicated they were far more concerned with “my events” and would have liked for it to be visible without having to scroll below “achievements”. They mentioned that they might want a quick way to be able to track their current and previously attended events. From this feedback, we considered moving “My events” higher up or even having a separate widget available on the bottom navigation for quick and easy access.
Design Iteration
Following our first prototype evaluation, we got the chance to re-iterate our initial solution after we took into account our successive interviews as well as the user testing we conducted. This was the first time that Edith decided to incorporate re-iteration in the course, so it was a unique opportunity to go back to our initial assumptions and challenge them once more given the new information we gathered.
In the reiteration activity, we identified three new user stories that we would have liked to develop features for, and integrate into the existing design. Specifically, we identified that users would want to be able to define preferences, and that this preference data should be used to curate the upcoming events feed. Previously we had not explicitly considered or integrated such curation, and have since realized it would be ancillary to provide quick access events that the users are more likely to attend, rather than having to revisit the search functionality each time to manually dictate such preferences. In essence, this feature provides something analogous to a ‘saved search’, but is much more personable in this form (i.e., there is a directly perceivable correlation with these preferences and the user’s profile, and thus appears to be the most natural place to put such a feature). Therefore, we have produced the necessary design sketch and user flow to illustrate our vision for the feature.
The next new user story relates to event coordinators. In particular, we identified a need for coordinators to not only distribute follow-up surveys after events, but to also collect the data recorded from the survey results, and aggregate them into some sort of report for their own use, or for distribution to other stakeholders. Our vision for this feature had been captured in the corresponding user flow. We believed that the event coordinator should be provided with a paginated list of responses, which they can press on each row to view the single survey results. Further, a button should be provided that allows the coordinator to aggregate results. In order to do so, they must be provided appropriate per-question report customizations, such as the type of charts or tables to generate (e.g., summary tables, histograms, scatter plots, etc). Coordinators should also be given the ability to omit questions from the report where applicable, such as questions where data aggregation is not applicable, such as long-form unstructured response type questions. Finally, we wish to provide coordinators to review the finalized report document, with the ability to share it with fellow stakeholders in an electronic form (e.g., PDF document).
Finally, the last user story that we conceived also dealt with event coordinators. This user story saw the event coordinator wishing to negotiate the reservation of a venue to host their event with the owner of the venue. Part of the reason why this feature had not been flushed out further is because we needed to construct interview questions that pertain to communication between event coordinators and venue owners, and interview the appropriate parties. Ideally, we needed to capture not only what each party would desire from such a feature, but also address potential breakdowns in the process. For example, we supposed that it would be necessary to provide a mechanism to indicate dates and times that a venue is available, yet we would have needed to consolidate our hypothesis on this matter first, otherwise we would have been designing solely based on speculation.
High Fidelity Prototype
This final activity revolved around evaluating and making improvements upon our final prototype: the high fidelity prototype. In particular, we collected and evaluated the suggestions we received, and where applicable, applied them to the prototype. Further, we used the feedback from our challenge reports and the respective presentation to make additional changes to what is to become our final high-fidelity prototype. The prototype has been constructed using Adobe XD, and currently includes all of our major features, such as but not limited to: the sign-up page, event feed, creation of an event, creation of a survey, user profile, achievements and points.
Given this final version, we then had users test our app via cognitive walkthroughs and heuristic evaluations. For our heuristic evaluation, our testers focused on the visibility of the system status, user control and freedom, error prevention, consistency, and aesthetics. Those were chosen because they reflected some parts of the app which were found to be lacking the most when compared to the other metrics. For the cognitive walkthrough, we asked our participants to instead create their account and set their user profile with all of the required information. We chose this task because we wanted to ensure that our starting process was smooth and understandable.
Our four testers gave us all valuable feedback, and it can be summarized by a few specific improvements we can make. First, some of our buttons aren’t very visible or easy to read, and our users didn’t know that those areas were clickable. An example of this can be seen by our List View button, which just looks like a header. Further, we encountered a lot of confusion in regards to the layout we chose. The users found there to be too much content on the screens which was overwhelming and disorienting. On that topic, the contrast and choice of color also turned out to be a little hard to read for our users. Given these suggestions we’ve made an effort to make the required changes to our prototype for our final presentation.
Conclusion
In regards to our specific project, from the feedback received I believe we bring to the table an innovative and fun way for users to participate in events in order to achieve community-driven goals. Our app includes all the essential features we initially envisioned, such as an event feed and a user profile that leads to achievements and friends. Even though we added more features than needed, such as different event views and surveys, we have remained loyal to our goal of creating a product that gives users the ability to set and achieve community goals. If we were to re-do this project again we would probably try to get most of our interviews at the beginning to get more user data as we move forward, as we noticed that we were still making several assumptions in the later parts leading to the final prototype. Aside from the one point, I think we did everything as best as we could and came up with a user-friendly, competitive and useful product that can be used by our target market to create and accomplish community goals.
Overall the course has gone over many aspects of the design process, from assumptions and hypotheses to prototyping and user testing. I found the material learned extremely interesting and valuable, especially because it’s so applicable to many fields in the tech industry that involve a product that needs to solve customers’ needs. I would highly recommend it to any other CS student looking to learn more about usability and customers in the tech world.
