Interactive Hi-Fi Prototype

Transcription

1 Interactive Hi-Fi Prototype Chioma Agu Joshua Browder Jasper Kajiru Rena White... Kampus Karma Do Yourself a Favour

2 Students on college campuses are constantly seeking favors and offering help to others. However, the means by which people ask for favors, which include sending mass s to a dorm or other mailing list and posting in group chats, are only marginally effective because they do not target the right audience or use the right channels. Kampus Karma provides a platform dedicated exclusively to facilitating favor exchanges such that any individual s request for a favor is seen by people who are willing and able to help. Similarly, a person who wants to help can easily find the right request to which to respond. A user can tap the Ask button on the home screen, which takes a user to a new ( Ask ) page. On this page, the user can post the details of her request. The user is required to enter the subject and additional details of her request, as well as set the expiration date and time of the request, which corresponds to the date/time when after which the user would no longer require the favor. The user also has the option to enter and set her location of where she d need the favor performed to enable other users close to the location find her request and respond to her request easily. The user has the option of editing or deleting the favor in the Activity section of her profile that shows the user s posting/request activities in the app. Only open favors can be edited. This task allows the user to address a core need of requesting help from a targeted audience to increase the chances of getting a positive and timely response.

3 There are two ways for a user to find someone to help or a favor to which to respond. The first is through the home screen. The home screen is a curated list of open requests. The list is personalized for each user based on past user activity and the user profile. During the sign-up process, users are asked to choose types of common favors they can perform, and they can edit the responses later in the profile. This enhances personalization and ensures that open requests are shown to those most able to fulfill them. Using the home screen, the user can scroll through requests, which are shown by their subject and expiration time. Once she taps a request, a pop-up screen opens with the additional details of the request. She then has the option to Pass on the request or Connect with the user to offer to help. To aid her decision to help a user, she can also tap on the user profile picture to view the user s ratings to ensure the user is a good citizen who also helps others. If she decides to pass, she can go back to the home screen to browse other open requests. Conversely, she can use the second method of finding someone to help by tapping the Near Me icon at the bottom of the screen. This takes her to a map view showing nearby users with open requests. These nearby users correspond to those who chose to add a location before posting their favor request. Tapping on a user on the map view opens up a pop-up screen similar to using the first method. The rest of the process to complete the task is the same as in the first method. Talking with college students revealed that people often felt a sense of obligation to return a favor. This task helps people fulfill that obligation by allowing them to help other people. People can also pay a favor forward so that they can ask for help without feeling guilty about not giving back in return.

4 Once the user taps on Connect to offer help to another user, she is automatically taken to a new chat with the user who needs help. The Kampus Karma chat bot initiates the chat by prompting both individuals to arrange to meet (if necessary). Using the chat, both individuals can communicate and plan the rendezvous. Once the favor has been performed and the request is met, the user can tap Complete in the chat. Tapping Complete prompts the user to rate the other party. In the event that both users cannot agree on a meeting time/location, either party can tap Unmatch within the chat. Tapping Unmatch causes the favor s status to revert to an open request so that it appears on the home pages and/or Near Me screens of other users who may be able to help. Tapping either Complete or Match ends an open chat, and causes the chat to disappear from the Chat page of both users. As such, at any time, a user s chat page only contains open conversations for favor exchanges. It is imperative for users to actually be able to meet or plan a way to give or obtain help. This task enables users to engage in those conversations efficiently.

5 Initial UI Sketch Low-fi prototype: UI flow for simple task (ask for a favor) Low-fi prototype: UI flow for moderate task (find someone to help)

6 Low-fi prototype: UI flow for complex task (arrange to meet) Our initial prototype opened to a home screen with 5 menu items: Notifications, Ask for Help, Match Me, Near Me, and Open Chats. Notifications listed items such as favor matches, opportunities to rate other users, and new chat responses. Ask for help included subject, details, radius, and expiration boxes. Once a user chose to post a favor request, they received a confirmation screen with the option to return home or pay it forward. The Pay it Forward button took them to the match me screen. Match Me was our initial concept for finding someone to help. The idea was that a user s profile would list things they were capable of doing and match would then provide them with a request they may be able to help with. Near Me was a map that showed all Kampus Karma users in the area, and showed users with open requests in red. Finally, Open Chats led to a list of all of the user s conversations with people they were matched with. When users were matched, a chat was opened with an initial message providing the requester s location.

7 Medium-fi prototype The biggest change from out low to medium fi prototypes was that we changed the home screen to a feed of favor requests rather than a menu bar. We made this change so that users can easily view requests, based on feedback from low-fi testers. We moved the other options to a menu at the bottom of the screen so that every screen could be accessed at any point. We also changed the primary screens to Home (the favor feed), Near Me, Ask, Chats, and Profile. Finally, the design of the hi-fi prototype was highly influenced by the feedback we received in section after presenting our medium-fi prototype. Our medium-fi prototype was notoriously devoid of color, but we implemented a consistent color scheme in the next iteration. Other design changes included using consistent text font and sizes, and adding headers to all main pages. We did not have any usability problem of severity level 4. However, our major usability problems of severity level 3 are detailed below:

8 In our medium-fi prototype, a user had to get rid of an open info/help dialog box by navigating to a different screen, using the navigation bar at the bottom of the app. We addressed this problem by getting rid of the info/help option on individual screens. Instead, we added 4 info screens that show up once the app is launched. These info screens guide the user on how to use the app. Removing the help option from each individual screen helps to reduce clutter on the pages, since users typically require help only when they are new to the app. The medium-fi prototype allowed a user to set either an expiration date or time of a request prior to posting. To increase user flexibility and control, a user can set the expiration date and time separately in the high-fi prototype. Initially, it was difficult to distinguish the user icon from other requester icons on the Near Me map. To enhance recognition, we replaced the requester icons with flags on the map, with each flag representing a requester s location. The flag is also a bigger than

9 the icon in the medium-fi prototype, so a user can find another user to help on the map easily and quickly. In the medium-fi prototype, a user s current location was immediately recorded and included with the details of the favor when the user chooses to post the favor. As such, all requests also showed up on the Near Me map (based on location). For requests that did not depend on location or was based in a different location from the current one, a user could not turn off or edit the location feature. The high-fi prototype allows users to optionally include their current location or enter a new location. If a user enters a location, then the request shows up on the map, otherwise, it is only displayed in the request feed on the home screen. The optional location feature allows users more control over privacy, and allows them to post location-irrelevant favors even quicker. A user could not save updated profile information in the Edit Profile workflow. However, we chose not to implement the Edit Profile workflow at all in the high-fi prototype. This

10 is because it is not critical for any of our three main tasks, and we decided to focus on the functionality of the 3 main tasks for the current version of the prototype. The next iteration of the prototype will contain this functionality. The medium-fi prototype included two scores for each user. The first is the rating which is an aggregate of all ratings given by other users with whom the user interacted on the platform. The second is a current karma score, which shows the difference between favors given and favors received. However, evaluators found that telling the difference between the two could be confusing, since there was no explanation of the current karma score. To address this problem, we retained the rating in the high-fi prototype but modified the current karma. Now, there is a straightforward sentence that states that a user has performed a certain number of favors and received a specific number of favors. This ensures that users can interpret the terms on the platform, since users are already familiar with ratings. Based on some of the minor heuristic violations, we implemented the following changes: i. Moved ability to view previous requests away from Ask page: This functionality is now an option in a user s profile page. This helps to decrease clutter on a page that facilitates a main and frequently performed task. ii. Added ability to edit and/or delete request: Users now have a way to correct errors even after posting, which enhances the user experience.

11 iii. iv. Separated history of favors given and favors requested: As such, there is less confusion for users, who are now able to quickly navigate to the right tab based on what information is needed. More details of a favor implemented as a pop-up: Users have to choose to pass on (deny) a request or offer to help in order to close the pop-up box. As such, users cannot just navigate out of the page with uncertainty about the favor status. With this change, users now have a clear indication of the task flow without loss of flexibility. We built our prototype using React Native and Expo. Using the third-party framework NativeBase, which provides cross-platform UI components for React Native and integrates seamlessly with it, we were able to get many built-in components, such as buttons, forms, and lists, which enabled us to develop and implement many functionalities in a shorter time period. Because React Native permits reusing code components, we were able to save a significant amount of time in development. Using Expo, we were able to visualize effects of code changes in almost real-time. However, there are some aspects of the tools that did not help our development efforts. Considering our limited prior experience with React Native, we found the learning curve to be steep. This was further compounded by the problem of poor documentation. As such, we were not able to easily and quickly find solutions to problems we encountered in the development process. Another issue we found was that React Native has a very high number of dependencies, and implementing a new functionality sometimes required us to import a new dependency. The primary Wizard-of-Oz technique we used in our high-fidelity prototype appears on the home screen. The home screen contains a list of open requests that is personalized for each user. However, the list is currently hard-coded and uniform for all users as we have not implemented and incorporated a personalization engine yet. This static list simulates a curated, personalized list. Almost all of the data in the prototype is hard-coded. These hard-coded data includes map, user profile, home screen/feed, chats, etc. However, the prototype allows a user to add favor requests, add chat messages to conversation thread (unidirectional), mark favor requests as complete, and

12 cancel favor requests, which update dynamically within the current session though all data is reset to default once the application is reloaded. There are many features and functionalities, which are not critical to our three main tasks, which we would like to add to a future iteration of our prototype. These include: Sign-up and verification UI flow (the app currently has a fixed user). A swipe-able list on the Home screen so users can choose to pass or respond to a favor even quicker. A truly personalized and curated list of open requests based on what each user is likely to respond to and fulfill. Ability to edit profile data and save new data. Live map that updates to reflect a user s actual location. Login functionality so that the app retrieves and shows user-specific data. Limit ability to rate a user to only the requester so that the requester rates the person who offered and provided help. Limited ability to modify a posted favor. Visual display/indication of the urgency of open requests. Given the time constraints, we decided to limit the features in the current prototype to those critical to the completion of the tasks but we are aware of these missing features, which will further enhance our app. Within campus communities, students often need favors that their friends may not be able to provide. Many students feel apprehensive about using existing channels to reach a wider range of people, since those channels have different purposes which often result in requests for favors being overlooked or ignored. Our goal with Kampus Karma is to provide a safe environment for students to reach a self-selected audience of people who will be willing to help. The ratings system in Kampus Karma will help to ensure community-policing using social proof. As such, users will be incentivized to good behavior and to offer help to others so that they may also

13 easily get help when needed. Using the tools we learnt in class, we engaged in a user-centered design process from choosing a problem to solve to developing this current prototype. The iterations and changes in design have been informed by users feedback and suggestions. Through this process, we have learned how to find a problem that represents a real pain point for people; narrow the scope of our problems using How Might We Questions; brainstorm multiple solutions; design, prototype and test a solution in order to develop a product that meets users needs. Going forward, we will continue to use these learnings to improve Kampus Karma and to address other problems.