Role: UI/UX Designer, App Developer
Date: May 2019 - June 2019
Links: Process Doc
DAWA is a mobile application built for CS 278: Social Computing. Our team of three was challenged with creating a new sociotechnical system using the concepts taught throughout the course. We chose to explore different interactions that take place on campus, hoping to come across one that could potentially be improved by taking advantage of technological tools.
Eventually, we decided to focus on how students exchange items with one another, asking ourselves how we could change this interaction in such a way as to benefit all parties involved. One method Stanford students use to exchange items are email lists. The format popularly used for these requests is “DAHA x”, or “Does anyone have a(n) x?”. Common items exchanged are Tylenol, chargers, watches, lint rollers, locks, and SD cards. On the other side, those who have items they are willing to give to others, such as books, microwaves, or fridges can ask “DAWA x”, or “Does anyone want a(n) x?” In addition to email lists, students go through Facebook Free & for Sale to request and sell items through posts.
The problem with email lists is that students only see what those in their dorm have. There is a lack of transparency in the offerings of other Stanford students, who have reservoirs of items to borrow/take from one another. The major problem with Free & for Sale is the lack of sharing culture on Facebook’s Free & for Sale as the culture is very much transactional and not around sharing with your community.
Thus, we created DAWA, a platform that allows Stanford students to borrow items from one another and see the “profiles” or inventories of those on campus. DAWA gives access to the hidden resources at our disposal. This maximizes the potential for students to share with one another and provides a broader set of items to borrow as the transactions are not constrained per dorm.
Our first prototype aimed to test how far students were willing to go for certain types of items. To do this, we identified three possible types of items that could appear in our social system: common, rare, and disposable. Common items, such as books and calculators, are shared fairly frequently, whereas rare items are exchanged less often and include items like bikes, microwaves, and mini refrigerators. Disposable items, like food and condoms, are ones that cannot (and should not) be returned to the original owner. We then posted three different listings (one for each type of item) in a Stanford Facebook group called Free & For Sale. Each listing had the same location (a dorm called Crothers).
Our main finding from our first prototype was that people were willing to travel outside of their dorms for the rare and disposable items. As for the common item, we gathered that the high probability of someone in your dorm having the item results in people being unwilling to travel further than their own dorm to obtain it, even if they were in dire need of it. In addition to gauging how far people were willing to travel for the three different types of items, we also found that students act cautiously when accepting common and disposable items from people they don't know. As a result, we decided to include interaction ratings for each user so others can determine how reliable and safe the exchange would be.
After conducting our first prototype, we felt it was necessary to take more specific measurements of the distances, so we created a Google Form that allowed us to determine ranges of distances that students would be willing to travel for each type of item. We asked students whether they would be willing to travel 0.5, 1, and/or 2 miles for each item. We based these distances on how far it is to go from the furthest side of main East campus to the furthest side of main West campus, which is approximately 2 miles. The results told us that for all three items, most students would be willing to travel around 0.5 miles, but unwilling to travel much further (even for boba). We took these responses with a grain of salt as some people were unable to accurately gauge how far these distances actually are.
.png)
For our final prototype, we wanted to observe the actual interactions that make up our social computing system, so we used Google Slides to make a low-fi version of our final application. In their own section, participantswere able to upload items that they were comfortable letting others borrow, serving as the equivalent to profiles in our final iteration. ollowing each upload, our team would sort each item into their relevant categories.
To understand how our target audience thinks of categories and to create a baseline for what categories initially exist, we asked participants to provide a category for each of their items, though they would not be allowed to create new categories in our final product. Finally, we asked our participants to look through each other’s items and email one another to go through the process of setting up a meeting time and location, the main interaction we chose to focus on for this prototype.
.png)
Because this prototype was released in the middle of Week 9, many of our participants were rather busy and unable to proceed to the second stage of emailing one another to exchange items. As a result, we only have one exchange from which to draw conclusions. In this single exchange, the borrower and lender settled on the details of their meeting fairly easily. However, in follow-up discussions with both parties, we found that they had difficulty trying to recall those actual details. In fact, they admitted that this was one of the main complications with using Facebook Messenger as a means to communicate with one another.
This finding drove the central feature of DAWA’s chat. To facilitate setting up a meeting, we decided to have a “floating message” in each chat that not only updates with meeting details, but also displays content depending on the current status of the exchange. By providing this feature, our users can simply open a chat to be reminded of the details for the corresponding meeting.
I primarily contributed to this project by coming up with the UI design, creating Figma mockups for each of the screens in the app. Because another team member had begun the development before the completion of my mockups (this was a project he had already been working on), it was difficult to integrate my designs into the existing code base. As a developer, my role was to implement the frontend to match the mockups as much as possible within the remaining week while also jumping in to fix any bugs my teammates ran into while developing the functionality.
%202.svg){kind=small}