Published on <a href="http://ift.tt/2se8tWS">| Prototyping: From UX to Front End &mdash; Medium</a> Marianne Sotto 
This case study details some of the our design thinking and the process my team and I used to redesign a multi-platform solution for our community partner, Hoods Guru for our third project sprint at RED Academy.
<h4>The Opportunity</h4>
As Canada’s largest city, Toronto is home to a distinct populace and is heralded as one of the most culturally diverse places to live. This diversity is displayed within the plethora of festivals and events that are available to Torontonians on a daily basis. But with such an extensive number of options available, one does not simply select an event.
Enter Hoods.Guru. They are a platform that allows users to discover local events and restaurants based on the mood they’re in. *Spoiler alert* We actually ended up redeveloping their idea, it so it wasn’t based on moods anymore. But more details about that later!
According to our initial conversations with Craig of Hoods Guru, they differentiated themselves from other discovery apps and websites because their results are unbiased. What does that mean exactly? Well let’s say you were in the mood for a music event in the city. The results could show Queen Bey’s Lemonade tour along with wherever the town troubadour was playing. Hoods Guru would display the shows of the biggest performers in town along with the little guys too. So whether you’re in the mood for karaoke, a comedy night, 0r live music — Hoods Guru is here to help you discover everything that’s going on in your hood.
The mission:
<blockquote>“Help people discover the best the city has to offer”.</blockquote>
Since they already had their app launched in beta, our initial focus was to update their website, which would push users to download the app. Prior to meeting with Craig, we reviewed both their site and app. We decided that it wouldn’t make sense to redesign the site and not the app. So we proposed during our first meeting with him that we wanted to deliver a cohesive multi-platform system. He was ecstatic and very open — whew! We were also quick to discover that Craig didn’t really have or know what the MVP of his app was. He talked about loving this feature from that app and that function from this app, but that’s pretty much what Hoods Guru was at the time — a Frankenstein app. And we didn’t just want to just completely rip off parts of different apps, we wanted to create a user-centred app! And so we explained to him our process, and what we were to deliver. He was helpful throughout the entire process, and very open to our suggestions.
Ultimately, we were able to provide Craig with an MVP. We redesigned their web experience, which pushed users to download their mobile app and discover the best the city has to offer.
*Note: Because we had 2 UI-ers on our team, they were responsible for taking my wireframes to the final high fidelity screens presented to Craig. Since I am also have a background as a designer, all the screens displayed in my portfolio and here on Medium are my own iterations, along with the logo redesign.
<h4>Research</h4>
At the time we were working with Hoods Guru, they had just launched their beta app on Android and they were primarily seeking our advice on how to redesign their web experience. Their sites function was simple: It served as a place for people to get information about what the app did, how it works, and a CTA to download it. Craig admitted the site was an afterthought. When I asked where his inspiration came from he answered “desperation”. They only decided to throw one up after they launched the app, so needless to say its functions were less than impressive.
<img alt="" src="http://ift.tt/2sO72LS">Hoods Guru’s original landing page. It’s main purpose was to get people to understand what the app did, and instructions and a CTA on how to download the app.
Since we were taking on both a website and app redesign, it was important for us to stay organized to complete our deliverables by the end of the 3-week sprint. We decided to split our team into two groups. For the sake of ease when referring to both these groups in this case study, I’m going to name them: #TeamAppFTW #TeamWebFTW. #TeamAppFTW consisted of myself (UX), another UX-er and 1 UI-er, and #TeamWebFTW consisted of 2 UX-ers and 1 UI.
<img alt="" src="http://ift.tt/2sey0PA">Hoods Guru’s original screens from the Hoods Guru app in Beta.
To remain organized and on schedule, we tracked our progress on Trello and had daily morning meetings on our newest findings and what was our expectations were by days end.
One of the first tasks for us was to validate the info Craig provided to us. He claimed he wanted to target young professionals, aged 19–35. So I created a questionnaire on Typeform to collect that precious precious survey data.
<img alt="" src="http://ift.tt/2sNQeVl">
Findings from Online Questionnaire and in-person interviews
Below are some of the highlights from the questionnaire and in-person interviews we conducted. In total, we ended up with 71 results from the questionnaire, and conducted 20 from our in-person user interviews.
<ol>
<li>Most people found out about events through social media (85%) and word-of-mouth via friends/family (83%). People often shared events they were attending with other people (81%). People were encouraged to travel further distances if they knew other friends were coming or if it were for a special occasion (i.e. friends birthday). — An overwhelming amount of people cared where their friends were going. This is echoed through the methods people found out events, their desire to share events with their friends, and their willingness to travel further.</li>
<li>The majority of our users surveyed planned at least 1 week in advance (38%), and a couple weeks in advance (33%). This meant the idea of selecting an event based on moods wasn’t going to work since people didn’t know how they were going to feel a week or more in advance.</li>
</ol>
<img alt="" src="http://ift.tt/2sezqKj">Some of the responses we received from our in-person interviews when asked what they wanted in a discovery app.
One of the initial thoughts we had in regards to the app was that Hoods Guru was the new comer in the discovery app scene. So without any incentives, why would people choose to download and continually use the Hoods Guru app over existing, successful apps and websites? Well one answer was to give away free stuff. People love free stuff! But that wouldn’t be much of a long term solution. So we needed to find out what made Hoods Guru special. What was its MVP?
We looked at other popular apps and sites that occupied the discovery event space: Dojo, Zomato, PHIND, Google Swarm, Facebook Events, YELP, Artery, Trip Advisor, Ticketmaster and Bandsintown to name a few. We looked at what their products specifically focused on, how did they differentiated themselves from each other, and what specific industry they were each designing for.
We also conducted a few different competitive/comparative analysis’ between apps/websites. We compared it to other discovery companies (i.e. Dojo, Zomato, PHIND, Google, and Facebook), companies who primarily used their websites to push users to download their app (i.e. Snapchat and Uber), companies whose websites and apps conducted the same functions (i.e. Flipboard and Medium), and companies that focused on organized their categories by moods (i.e. Songza and Spotify). Basically we looked at comparing A LOT of apps and sites and the types of methods they used to solve the problem.
<img alt="" src="http://ift.tt/2sNwgKv">Users event preferences visualized above base don the data taken from a questionnaire we conducted. The larger circles indicate the events of most interest.
We discovered that there were already other successful discovery apps and websites for finding restaurants/bars, and parties/nightlife. Weddings and free events were untapped markets, however. We then realized we found our niche! We decided to focus on creating an app where people could find and crash weddings happening around town!
<img alt="" src="http://ift.tt/2sey1TE">Who doesn’t love a good wedding? A wedding crashers app was exactly what we envisioned for Hoods Guru.
Just kidding! We eventually decided to create an app that allowed users to search for unique events in the city. One that also allowed them to add and create their own events and share it with their friends. We found there was definitely a gap in the market in terms of services that allowed you to find unique events all in one place. A lot of people used multiple discovery sources to find events, but that gets tedious and is very unorganized. Even so, to find an “underground” event, you’d have to know someone who knows someone, who knows someone on the inside. We wanted Hoods Guru to be that someone who was able to tell you about that latex fetish party happening on Friday in Toronto&#8230; And keep all your &lt;s&gt;fetishes&lt;/s&gt; events everything organized.
<h4>Planning</h4>
<img alt="" src="http://ift.tt/2sNKmeP">
The research we conducted is ultimately what informs each design decision we ultimately made. So what exactly was our research telling us?
First: we knew it couldn’t be a mood based app since a good number of our users were planners.
Second: We now knew what the MVP was: A discovery app for underground events.
From there, we decided to create our persona based on the information we collected.
One of our users was Jordan, who is our “Tastemaker” persona. She prides herself for being one of the first to discover the newest artists, hottest venues, and trendiest galleries. Jordan’s friends often turn to her when deciding where to go out, and like her friends, she is always willing to try new things. She finds out about events most people wouldn’t know about by scouring the web, sifting through multiple options, ads and mainstream events, which she finds annoying and tedious.
<img alt="" src="http://ift.tt/2seaTVw">
During this phase, we began prioritizing the features for the app as a team. We began by writing down all the features that could potentially be included for the app and the website and plotted them into a chart with the headings “Must Haves”, “Nice to Haves”, “Don’t Needs”. We referred back to our persona persona asking if this is something she would need, backing up our reasoning.
We also created the user flow to determine how Jordan would be using the app to reach her goal of finding an event.
<img alt="" src="http://ift.tt/2sNN6so">
My partner developed an emotive customer journey map based on the current experience. We used this to determine which parts of the flow needed the most help.
<img alt="" src="http://ift.tt/2se8sSO">
<h4>Design</h4>
App
While my partner began developing the site map, I began sketching initial placements of the features onto paper. Once we decided we were happy with what we had, we shared our paper prototype with #TeamWebFTW. Once we were generally happy with everything, I went forward with creating the mid-fidelity wireframes on Sketch. If there were stages where we were uncertain about something, we immediately put it to test on users. Eventually we ended up with a mid-fi wireframe we felt worked well enough to be brought to the hi-fi stage.
<img alt="" src="http://ift.tt/2sNReZI"><img alt="" src="http://ift.tt/2sewahW">
While our UI began working with my wireframes, we still continued to test the app and make rapid iterations based on any new feedback we received, making improvements when necessary.
Logo
<img alt="" src="http://ift.tt/2sNQ7Jo">Hoods Guru;s original logo.
We also took the task of redesigning their logo so we could provide them with an entire cohesive solution. We asked users what kind of app they thought “Hoods Guru” was. Some of the responses included “selling sweaters?”, or “yoga app?”. Needless to say it was a confusing name, with an even more misleading icon. Even Craig agreed he wasn’t very fond of it. He admitted he got the logo from 99 designs. *shudder* I designed the logo below as a new option.
<img alt="" src="http://ift.tt/2sesHju">
The idea was for it to be very simple, easily recognizable, modern, and easily scalable. The more obvious visuals are the letters H and G, but the combination of the letters are also meant to mimic a topical view of a map, or a “neighbourHOOD”.
<h4>Prototype</h4>
View the <a href="http://ift.tt/2sNTEar">prototype</a> on Invision.
1. On-boarding
<ul>
<li>Initial screens help create a positive and welcoming experience for the user prior to even opening the app.</li>
<li>While they may be encouraging users to download the app, its also a way for them to get oriented with the app and how to use it. According to some of our interviews, some people deleted apps after a couple minutes if they couldn’t figure out how to use it quickly.</li>
<li>Based on some of our usability tests, people expressed positive feedback on how easy it was to navigate and use the app.</li>
</ul>
2. Facebook
<ul>
<li>We wanted to integrate the option of allowing users to log into the app via Facebook for a few reasons:</li>
<li>First “Password Fatigue”. Its likely someone downloading a discovery app has Facebook, so its much easier for users to just click a button to log in, no need to make a new account, and no need to remember another password.</li>
<li>Second, users would potentially receive a more personal experience. Hoods Guru can access information from users’ Facebook profiles and perhaps provide them one day with more personal suggestions for events.</li>
</ul>
3. Navigation
<ul>
<li>One of our original iterations included a slide out menu. We decided after testing not to implement this feature, since it needed initial instruction and added an extra step in our users’ journeys. This also made the navigation available from any page, and allowed users to enter any page within the app within three clicks.</li>
<li>Home: Where users would first land when they logged into the app and would go to anytime they wanted to start a new search.</li>
<li>Discovery: Some our users didn’t know what types of events they wanted to attend, and were simply interested in discovering new events near them. This option was created for them in mind. They’d simply enter a location and date, and events from all categories were randomly populated.</li>
<li>Create An Event: Where you can create private or public events and share with friends, which is the main purpose of the app.</li>
<li>My Events: Users can view all events they’ve saved/are interested in. If friends also invite them to events, they would show up in this section.</li>
<li>My Profile: Access your settings, edit your profile picture, view past events, add friends, view their profiles and past events (that are publicly shared).</li>
</ul>
4. Moods
<ul>
<li>Displayed a list of event categories instead of moods. Our decision to eliminate this was based on the results we conducted with user tests. Different categories were interpreted differently by different users. To determine the category titles we used on the app, we asked users to tell us what types of events they thought they might find under the given titles, and conducted contextual inquiries with minimal instruction.</li>
</ul>
5. Home
<ul>
<li>The majority of our users were planners (38% planned one week in advance and 33% planned two weeks in advance), so the date and location were placed prominently on top. After these sections were filled in, then their options would populate.</li>
</ul>
6. Results
<ul>
<li>After conducing some user tests, we found having a full sized map would be most beneficial to users. It was far too cumbersome for users to scroll around a small map. The updated version allowed them to toggle back and fourth from map view and event results.</li>
<li>You could enter the event details from one of two ways: either clicking on one of the points on the map, or one of the event results.</li>
</ul>
7. Event Page
<ul>
<li>Displays the essential details of the event: title, description, price, date, and location, which is what our users found most useful when selecting an event.</li>
<li>We also wanted to make it simple for them to share it with their friends, so there is an option to do so on each event, as well as an option to save it to your own events page.</li>
<li>If there was a ticket that needed to be purchased, we wanted that to be easily done within the app. It also made it possible for Hoods Guru to track tickets ticket purchases coming from the app.</li>
<li>If they clicked “take me there”, it would open their maps, and (if their location services were turned on) it would route them to the venue.</li>
</ul>
<h4>Summary</h4>
One of the most challenging parts of the project was the redevelopment of Hoods Guru’s MVP. While Craig was very open to any suggestions it was still very rewarding to hear the direction we eventually took Hoods Guru in was one they were already considering. Now he had all the research and data we collected to back up what his users wanted.
<img src="http://ift.tt/2sem40o" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2sNQ5RM">What’s Good In Your Hood?</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s Good In Your Hood?

The Opportunity

Top Stories