Final Report

Who are we?

We want to help inexperienced daters form connections by helping make conversation smoother. This app aims to guide people who have just begun to date, or those who experience some degree of social clumsiness or anxiety. Essentially, DateMate leverages the discreet form factor of the Moto 360 to provide contextually relevant questions during a conversation. It will help daters come up with thoughtful questions, and help them get out of a rut when they are at a loss for words. DateMate helps you… be you.

Brainstorming process

When pondering possibilities for projects, we relied on spatial organization. We sorted categories of ideas in physical groups of Post-It notes. Within each category, we chose our favorite. We had a couple of fun ideas that we liked in the end, a bird-call identifier and a story prompter being among them. When honing in on the final idea we would iterate and build upon, we decided to build DateMate because it seemed both challenging and rich in possibilities.

Intermediate and final design sketches, variations, and ideas/Wireframes

This is the listening screen on the watch. We made several changes to this interface to accommodate user feedback we get from user studies:

• We changed the icon to fit user's mental model better - the previous icon can be interpreted as heart rate.
• We cut the number of words considering the size of screen is small and decreasing the number of words also reduces the processing time for users.
• We changed the background color from white to black to make the activity less noticeable and conserve more battery life, but in the meantime still providing feedback to users that the app is actively listening.

Similarly, we used iconography in favor of words to quickly let users know they are talking too much.

We put a lot of though into the topic suggestion screen on the watch. We began with the prototype on the left. When we showed the left screen to users in the wizard of oz experiment, they expressed concerns about not being able to read the questions quickly enough. To help them out, we looked to the theory of rapid serial visual presentation, or RSVP. The experimental model has been shown to improve speed and ease of reading up to 12 words per second. This is reflected on the right side - words flash one by one.

However, we decided to revert to our original design after we realized that RSVP required focused attention when reading the text, which would take away the focus from the date. We want our app to help the user with the date, not replace the date. This is a perfect example of how design iterations helped us reflect on the goals of our app and achieve the best result for the users.

In this screen, we add a new date on the phone side. As shown in the screenshots, it also underwent significant changes:

• During our heuristic evaluation of the app, we spotted our app violates user control and freedom as the user is not able to edit the date info after creating it, so we made the dates editable.
• The app also violated error prevention as the date and time was in the form of a TextEdit, hence the user could enter anything the want. We changed that to sliding and selecting to prevent errors.
• We decreased the number of colors we use across the whole app to make the design more consistent.

Competitive analysis

DateMate stands out from the current existing apps in three ways:

• Currently there is no production level applications on the Google Play Store in this specific area.
• If we lower our searching criteria, there are a few similar apps made by individual developers, but all of them have a poorly designed interface. Moreover, they are general conversation helpers and the topic suggestions they provide are inappropriate for dates. The questions these apps generate are more for entertaining purposes, like “Do you know that ants do not sleep”.
• The current existing apps do not utilize real-time voice recognition to generate topics automatically and intelligently. In addition, none of them have a watch component, so it is highly unlikely that users will use the current apps for a date, as looking at the phone would be too distracting and obtrusive to the ongoing date.

Personas

Our persona evolved out of personal experiences and user interviews. We pictured a 20-something, tech-savvy. They want to form connections with their dates, but are kind of awkward and nervous. They don't have extensive experience in going on dates. On a date, they want to avoid awkward moments and keep their date intrigued/entertained. They still would like to personally connect with the date, and remain relaxed and confident.

Scenarios

Let's imagine our persona, named Alison, who is going on a date with someone she met at a small concert. Alison, after getting home, opens up DateMate and adds the time and place for the date, along with some keywords that they remember about the person. Before starting her date, Alison pulls up DateMate and lets the watch know to start listening. She and her date go to Kiraku, a small, quiet Japanese izakaya place. During the date, she and her date have good introductory conversation, but then it dwindles. Alison checks her watch, and then is reminded of a topic they previously discussed. She comes up with a followup question, and the date keeps moving.

User studies, details, and findings

We decided to conduct our user testing with a Wizard of Oz experiment. Many choose to go for their first dates at a quiet and romantic restaurant or cafe, so we did the testing in Julie’s Cafe. 

The facilitator greeted the user when he/she arrived at the testing location and introduced our application and the testing procedure, which also included introducing the user to his/her “dating partner” (one of our group members, who remained impartial throughout). Afterwards, the facilitator demonstrated a task on the phone interface to the user (with the app loaded on an actual Android phone): setting up a date in the phone app to familiarize the user with the application. The user was then given the Moto 360 watch with a stickie attached to the surface that showed the screens of the watch app.

The computer and the observer sat at an adjacent table. The observer took notes about the interaction between the user and the watch throughout the conversation. The computer listened to the conversation closely. When there were silences, the computer selected a premade round stickie note with a topic and stuck that on top of the watch, with as little interruption to the user as possible. The computer performed the same action when there was need for follow-up questions, as well as when an alert was created to stop talking.

We got great feedback for our chosen tasks:

Task 1: Maintaining balanced conversation by not talking for too long

• User 2 liked the icon and look we chose, but would like the option to dismiss the notification that pops up by shaking her wrist. She would also like the app to remember that she ignored the notification.

Task 2: Getting a question/topic when the conversation is slow (awkward silence)

• User 2 had concerns about feedback - the system did not let her know how often or if it was listening for silence, since it showed a black screen instead.

Task 3: Getting a followup question when conversation is moving

• User 1 wishes there were more control. She was concerned about getting stuck with uninteresting topics.

Final design including screenshots of high-fidelity version of system across representative tasks

Technical challenges and important information for implementing and/or executing and using your project on a physical mobile device

One of the first technical challenges we faced was deciding between having voice recognition be on the phone or the watch as it was a tradeoff considering ease of access vs computational power. The application of listening to the user was the same on both watch and phone so there was no issue of capability, but each device offered it’s own advantages to being the listener. The result we came up with in the end was a compromise between have the watch listen using google voice, but transmitting the data back to the phone to be processed from its raw form to the final keywords sample that we wanted displayed on the watch.

The next challenge was deciding how we were going to actually interpret the data into meaningful information as none of our members actually had extensive knowledge of any Natural Language Processing. In the end, we decided to use an external API called Meaning Cloud which would take the sentences we sent and return a list of keywords which it determined to be the topics of the conversation. This allowed us to not only offload not only the algorithms needed, but also the processing expense, enabling our app to react with data almost instantaneously; a feature critical to effective dating.

Finally, our last challenge was figuring out how to make use of the topics which we had extracted in order and use them to interpret scenarios for our dating audience. We wanted to service situations that could range from awkward silences, flowing conversations, and even talking too much. After brainstorming about the process for quite some time, we were able to come to the realization that all of these conditions could be heuristically evaluated by the number of topics returned by meaning cloud. Through user testing various scenarios, we determined that having more than 6 keywords bordered upon talking too much, at which point the watch would remind the user. When 0 keywords were returned, it was a sign that there was clearly silence as no topics were detected in the silence or awkward phrases, in which we would offer a random conversation starter. Lastly for any keywords in between, we asserted that the conversation was going rather well, and we would offer the keywords returned as mere assistance should the flowing interaction come to an abrupt stop.

Summary of project and resulting novelty and value for users

We learned a lot about user-centric design when doing this project. They revealed a lot of things that are obvious, yet obscured to you when you are a designer, like offering multiple topics for discussion rather than just one. It's been a really great experience for all of us to actually apply many of the concepts we learned about in class such as contextual query or Oz experiment for the actualization of DateMate. While the resulting product may not have been exactly what we envisioned when we first decided upon it in our design 01, we're very excited for the final iteration (at least final for now) of DateMate and all the creative jumps we made throughout the iterative process. It’s really something different that we don’t think can be found anywhere else in the market related to the topic of dating. As we’ve discussed in our competitive analysis, none of the current applications on the market try to even use real time voice analysis to assist the user in their dating experience. This alone allows users to get real time updates that cater to their specific conversations and allows for a more organic experience as opposed to one that forced by a stale idea generator. Furthermore, DateMate pushes the boundaries of how visible an application can be during an intimate scenario as it is the first to make use of the smartphone to allow the user to get constant updates in a convenient fashion.

Video: DateMate Demo