Dog Dating App

Project 9:Final Report

Aekta Shah, Yulia Zileeva, Sean Holahan, Mallory Loomis, Jeremy Stern

Problem
There are 43 million households that own one or more canines in the United States alone. With
the total population counting in at over 73 million, it is evident that there are plenty of dogs that need
attention. While most pets need daily attention and care, dogs require extra care and generous
exercise to keep them in shape and out of trouble. Many dog owners are faced with the struggle of
having to give their canine companions the attention and care that they need to flourish, which takes
away from their time to do other things such as socialize with friends. Dog Dating App (DDA) was
created to cater to the needs of the busy and technologically connected dog owner.
Our target users are dog owners of all ages and technological capabilities, but we believe our
application especially caters to canine carriers who have only one dog and are below the age of 35
(seeing as people with only one dog would be looking for more opportunities to meet up with other dog
owners for walks/playdates, and most people in that age range are technologically savvy enough to
pick up the app and understand how to interact with it from the get go). Additionally, users who live in
cities with fewer dog parks and other locations for playtime may find this application useful to
connect them with such venues that they were previously unaware of.
The main tasks that our application would help users complete are: scheduling planned
outings or events with other DDA users, connecting users locally via the map mode, and finding
opinions and advice from other users through the ask advice feature in the feed. It is our hope that
users of this app will be able to complete these tasks much more efficiently using DDA.

Design
Design
.
Briefly describe the final design of your interface, including any redesign you did after
user testing. Illustrate with screenshots. Point out important design decisions and
discuss the design alternatives that you considered. Particularly, discuss design

decisions that were motivated by the three evaluations you did (paper prototyping,
heuristic evaluation, and user testing).

Our goal was to create a simple and understandable social network that connects dog owners
to their community in a variety of different ways. We tried to tackle these problems in a simple and
familiar way, so to allow the user
to understand and use the full
functionality of the application.
FEED
The homepage/ feed of the
application was designed to
emulate facebooks feed. Allowing
the viewer to view Events, Posts,
and Blog Questions in one
seamless viewing experience. We
experimented with a tiling design,
but ended up resorting to a more
mobile first design, allowing each
post to take up the full width of
the screen and easily display
necessary content. The paper
prototyping that we did showed us that our initial placement size, and icon for the Post Button was
detrimental and hard to recognize for a novice user. This lead us to make the button, bigger, and
represent it as Write Post instead of merely alluding to its purpose with a + symbol.
We had little to no negative feedback for our heuristic evaluation, the main problem being that the
background being black was too much of a distraction. After user testing we got comments that underlined
profile names misled people to thinking it was a clickable link. We intended it to be suggestive as to future
usability but not as a functional feature within the task specific demo. This could be seen as a external
consistency problem if we did not mean to represent it as a link.

MAP

The map mode was where users could go to see the location of friends, dog parks, and possibly dog
related businesses (in a full version.). This feature was to emulate apps like waze, using a map API in
the future for full functionality. Paper prototyping gave us feedback that the share location button was
hard to recognize since it seemed to be a part of the legend. We fixed this by make the share
location button a popup when you enter map mode in the real prototype, making our time sensitive
task clear and readily available. We also got suggestions to include friend names below where they are
located. Although we liked this idea, we did not want to clutter the map at first glance. We decided
to make the paw icons clickable, so that information appears on the user when a paw is tapped.
In our heuristic eval, we realized that we did not fix the same visibility problem with our park
icons, and that our users could benefit from a similar design, this was a problem of internal
consistency. We also got comments that the white text on a cyan background was difficult to read,
so we changed the text to black so to make it more visible and consistent with the other text.
In user testing it wasnt obvious that the tree icon was an icon/held park information. Some
users were not sure that the map items were clickable at first glance, while others simply had trouble
finding the paws in dark areas of the map. We would fix this by changing the color of the icons to
have the same color, or atleast border, so as to unify them and imply that they have some common
functionality.
CREATE EVENT

Our create event was created as a popup so to not distract from some activity in progress,
and garnered the least amount of feedback. It showed no problems in paper prototyping, and in our
heuristic evaluations, the only problem was that the calendar icon overlaid with the title of the event
post that was created. This was more of a bug than a design choice that was quickly fixed. Our user
testing brought feedback that it would be helpful to include a calendar to select a date, rather than
manually input it in, this was a great suggestion that we will use moving forward! Overall the users
enjoyed this interaction as a pop up and felt it was a clean and simple design.
heuristic evaluation - The calendar icon overlays with the title of the event post created.
user testing - calendar widgit to make date selection easier, public private

Implementation
We began implementing this project with a Bootstrap template. We wanted to get a prototype
up and running as fast as we could, so we found a free Bootstrap web page template that we
ultimately transformed and made our own. We used it as a basis for our design, which was a great
decision as we wanted the app to be friendly and clean. Bootstrap was the perfect option for us to use
as their style is exactly that, friendly, clean, and easy to use.
Next, we modified the template to fit our needs. We created a feed with example posts to
display each of our types of posts: Event, Advice, and just a regular Post. With these post options, we
knew we wanted a way to differentiate them. This allowed for us to make our design decision of
assigning a different color post to each type of post. As observable on the app, green is an event, blue
is a normal post, and red is an advice post. In addition to color coding them, we also decided to give
each post a different logo. We chose a calendar for the event posts, a pen and paper for the normal
post, and a question mark for the advice. We believed that these design decisions would lower the
mental capacity needed to use our app and that users would be able to easily identify what they are
reading on their feed.
We originally chose a black background, as we thought that it looked modern and clean,
however we did run into a problem with this that did affect the usability of our interface. The black
background hid our paw print icon on our map mode page and users found it hard to understand what
the paw prints meant on the map. This was causing issues with performing tasks using the map mode
page. We ultimately changed this by changing the background to white in order for easier identification
and reading.
Overall, we kept our design and implementation pretty simple and this allowed for easy usage
of our app. We tried to make it as simple as possible so that there would not be any confusion for the
user. We wanted users to be able to learn how to use our app right away. In the next section, we will
discuss our evaluations from users and it will be easily observable that our design was mostly
pleasing to our users.

Evaluation

For this project we conducted two rounds of user testing - one for testing paper prototype and
another one for testing our web app. For both tests we tried to find different representatives of our
persona - dog owners of all ages who are familiar with technologies at different levels and who not
necessarily live in the city.
After paper prototype testing we found several major issues:
Visibility of some major UI elements including post button, share location button
Understanding of map page was challenging for most users
Public vs. Private concept wasnt clear
An idea of friends wasnt obvious
After analyzing those issues we made a conclusion that since our app wasnt supporting
friends concept it was confusing for people to differentiate public and private types of events. When
designing our app, we had a concept of tinder in mind, where the app is public and available for
everyone, but you only see people who are close to your location or who fall under your preferences
configuration. Thus, we decided to remove functionality of making events private/public unless we
introduce a friends concept in the app. In addition to this change, we decided to make important
buttons bigger and more clear for users to see.
After web app user testing we received a lot of different evaluations from our classmates, and
we grouped each main page related problems together and assigned severity rating to each. We also
separated them by bugs and recommendation/suggestions. We first tried to address bugs with our
system, and then considered other peoples suggestions to implement in the app. Here are the
following major issues:
Map Page
Some icons werent clickable - major
Static map - suggestion
Confusing map legend - major
Navigation for map is not highlighted when on that page - major
No option to hide/show current location - suggestion
Welcome Dan label was taking users to the wrong page - major
Dark background color makes it difficult to read on it - major

 Feed Page
It is possible to submit forms with no text in it - major
Add comment feature not working properly - major
Underlined labels that make users think they are links - minor
Inbox messages feature - suggestion
Delete/edit posts - suggestions
After careful analyzing of all problems we made several changes to our final version of the app.
We changes the background color to white which makes it easier for users to read, as well as makes
the whole design more friendly. We made all icons on the prototype map clickable, which would open a
modal with corresponding information in it. Some of the UI ideas we had for all modals we have in the
app was to make them take up the whole screen, as this app was designed for mobile, and it makes
user focus on one specific tasks and helps avoid errors when information is presented with no
distractions. When thinking about hide/show current location feature we decided to not introduce it
before introducing privacy settings/friends concept, as we thought it would create confusion for users
just like it happened with private/public events. From some of the suggestions that other people told
us, we decided to add functionality to delete posts. We also added inbox messages feature to our app,
though it is not functional right now, but we wanted to show what it could possibly be used for and
how it could be represented in the app.
Overall, evaluations from other classmates had a very good feedback regarding user
experience and functionality. There were major bug findings that were critical to solve. Also, most
people provided us great feedback on things they found were confusing or not clear, which helped us
improve user experience, visibility of features and elements, and their obviousness. Some people had
very valuable suggestions that we were able to implement in the app and that improved overall
understanding of the purpose of the app.

Reflection
Reflection
. Discuss what you learned over the course of the iterative design process. If you did
it again, what would you have done differently? Focus in this part not on the specific design
decisions of your project (which you already discussed in the Design section), but instead on

the meta-level decisions about your design process: what features to prototype, what
prototype techniques to use, and how to evaluate the results.
Throughout our design process, we learned about several different techniques that worked
well for designing a prototype and other techniques that did not work as well. The user personas and
scenarios were a great way to brainstorm tasks that would be helpful for our user base. All three of
the original tasks we created from the start of our project are built into our application. They have all
received positive feedback and testers have confirmed that they are useful tasks for dog owners.
For paper prototyping, we were able to determine which features would be the most useful in
our application and which features were currently too complicated for users by having our first round
of user testing. However, we found that the paper prototype was misleading for some people simply
because it was not an actual computerized interface. It was especially challenging for testers who
had a background in technology. They had trouble determining where to click and how to enter text.
The heuristic evaluation was helpful because we were able to determine where to make design
changes in order to improve readability and visibility of features, and fix critical bugs. We received
valuable feedback on overall user experience, as well as great suggestions that we were able to add
to our app.
The user testing on an actual smartphone was more useful than paper prototyping because
users actually used a device that the app would appear on if it were live. It was easier for users to
determine where to click and how to fill in text options.
If we were to go through this process again, we could have made our paper prototype more
realistic or tested with users who werent as technically savvy. A lot of feedback we received was
about friends or privacy settings, thus it would have been interesting to prototype those kinds of
features if we were to do it again. We would also probably have used some of the modern web
techniques and libraries available (Cordova, Ionic), which make it easy to program for mobile. Overall,
our process was very enjoyable, we received a lot of positive feedback about our application, and were
able to carefully analyze evaluations to make it even better.