Trill
Scope of Product
I was presented with a project brief from a client. It detailed the current state of the product and what was needed from a design perspective.
-
the client stressed that it was prelaunch
-
we would be working on the MVP (minimum viable product)
​
The app's premise is to provide a unique online dating experience by allowing users to create a plan or event where potential dates show interest in attending that in-person event.
Taking the online dating experience offline, Trill aims to enhance your social life with experiences that matter.
My Main Ones
I worked alongside three designers. We divided the team according to task roles. For example, since one of my strengths is organization, I took charge of setting up team meetings, and deploying the various software tools we used.
My Roles
UX Researcher
UX Writer
UI Designer
Tools used
In the kickoff meeting, we established who we were and why we were the best fit to work on this product. We needed to ensure that they were going to be a good fit for us, we asked them about their life, their work ethic, and what they wanted and expected. By the end of the meeting, we were all aligned with the team structure and product expectations.
Searching for our perfect app
To understand the ramifications of a new dating app, we needed to get information on the market space and how it currently works. I advocated for, and the team agreed to create a visual competitive analysis.
​
The analysis allowed us to compare direct and indirect competitors in the market place:
-
we analyzed the language (tone, keywords)
-
colors
-
UI elements (buttons, form fields, cards)
Direct competitors
Indirect competitors
Color Palettes
Voice & Tone
Resoundingly we found that dating apps used what we would describe as an open, forward tone. Bumble used phrases like, "we ask everyone on Bumble to be kind and respectful." Hinge has its mantra of "the app designed to be deleted." Hey Vina used words like "discovery" instead of "meet" to express exploration within the app.
The On & Off Dater
We utilized these necessary UX methods to provide us insight into the market and to lay the foundation to understand the users.
Based persona archetype the client provided, we created a journey map that gave us an insight into the feelings of dating app users. The persona archetype is known as the On & Off Dater, a person that downloads dating apps as soon as they hear about one and then deletes it as soon as they had a negative feeling about their experience. And in order to give the persona a bit of personality, we name him Jeffrey.
Key takeaways:
-
the on & off dater will download and delete various dating apps on a whim
-
throughout this process, they will experience emotional ups and downs
​
By understanding the fundamental struggles of our users, we anticipated potential pain points, and we began to devise a product strategy that addressed the needs that our users had.
Our First Look
Now that we understood the market and the user, we began to conceptualize our app. We knew that this would go through a number of iterations, but at that point in the design process, we had the information needed to visualize remedies for pain points that we identified.
With the above UX techniques implemented, we began with concept sketches. Each of us drew our own, and then critiqued one another sketches. For my part, I focused on the profile view of the user. I knew that a profile view would be central to the app experience.
Important elements included in Profile sketches
-
the profile was modeled after Instagram per the client's request
-
users can edit from any screen in order to maintain good UX heuristics
-
users said personalization was important, so we included the ability to add a background image in addition to the standard profile picture
-
key information (like name, city, and age) are displayed below the photos in keeping with the competitors
-
the tab pattern is used to allow users to quickly jump between sections in the app
Another series of sketches created by another teammate, but conceptualized together as a team, was the scroll navigation on the Home screen. Our client told us it was essential for the app not to use the traditional swipe action found in popular dating apps like Tinder and Hinge. They wanted something that was viewed as less "hasty," and more friendly since the swipe interaction can be observed as dismissing someone.
Concept Debut
My sketches and those of my team allowed us to form a preliminary concept of the app experience. Initially, we provided feedback to one another, made the necessary changes, and then we created a prototype to be tested with users. Iteration is vital in user experience design and doing it as often and as soon as possible was essential.
The low-fidelity prototype that we created combined the sketches and made the flow interactions clickable. We needed users to feel the initial flow of the app.
Recruiting users to test required us to create and deploy a survey that inquired if the individual taking the survey used dating apps, and then they were asked if they would be willing to be apart of concept testing. We were successful in recruiting five users to test. Since this is a test to analyze a low-fidelity concept, we wanted to get open feedback from the user. This included but was not limited to their reactions, instincts, and general recommendations.
We synthesized the users feedback:
-
100% of users tested liked the scroll navigation utilized on the Home screen. It was reminiscent of their Instagram experience.
-
80% thought that the profile screens needed to include interest. Such as things the user liked to do, movies, tv shows, music, etc. Something that the concepts did not already include.
-
users overwhelming felt that we needed to reconsider the naming scheme of the app. They felt that Home should change.
Tweaking our concept
We continued along our predetermined design process by now becoming laser-focused on the design structure. A site map allows us to conceptualize the scope of the app.
​
Site Map contains:
-
main sections of the app and the associated screens that will be in an app
-
for example, if the user clicks on Events, we need to take into account any potential screens that might exist within that particular section.
Based on the feedback generated from the concept test, we began to play around with new names for the Home section of the app, the place where the user will start when they launch the app. We decided to rename it to Discover, since the user will be discovering new people to interact within the app. We then laid out the rest of the app experience on the site map. The next section was Messages, a place that users could organize the messages that they had with other users. And since we know that the main focus of this app is Events, we needed to have that section be paramount in the flow for the user.
Taking this concept a step further for greater consideration, we created user flows. If a user was going to create an event, we needed to be able to play out the actions that they would have to take within the app. That is where user flows come in.
Designers don't, as much as possible, want to be thinking about the intricacies of flows when they are making higher fidelity app concepts. That slows down the work and does not allow you to conceptualize all aspects of the app. It is better to do this as soon as possible, as long as enough data has been generated.
With the Site Map and User Flows and the results of the first concept test, we were ready to create more detailed designs. We call theses mid-fidelity wireframes. We created these wireframes by adding more detail digitally, instead of hand sketches that we used for the low-fidelity prototype. We started to think about the user interface elements and where they would live on the screens. We accounted for buttons, form fields, and general text. By taking these considerations into account, we began to visualize the hierarchy of the app while making sure that the layout made heuristic sense.
As observed in the mid-fidelity wireframes below, the feedback that the users provided in the concept test were taken into consideration and conceptualized. The interests are not only viewable on the user's profile, but in the new Discover screens, you can see their interest in what we called their profile card. And because the users enjoyed the scroll navigation in the app concept experience, we ran with that idea and solidified its utilization.
View complete Mid-Fidelity Wireframes - Iteration 1
The magic of mid-fidelity wireframes is that you start to get a structured look at the app. The user flows become digitalized, and you begin to see what works and what needs reiteration. One of the biggest lessons that we had during this iteration phase was that we needed to reconceptualize the create an event flow. By this time, we had met with the client and they provided us with more information that we needed to implement into this particular flow. In the sketch concept prototype, the user would choose the date of their event by using a scroll wheel interaction, we learned that it would be better if we implemented a more tradition interactions, and we decided to include a calendar view. The user could click the date on the calendar to confirm the day of their event. Sometimes you don't need to reinvent the wheel to be effective.
A night on the town!
We created the mid-fidelity wireframes and tested it with five users. We call this a usability test. Since we are testing the ease of use with the users. It was imperative to test the wireframes with five users. Because based on academic research, beyond five users, the quality of the feedback received can be reductive. And having less than five would not produce enough feedback. The client provided one individual with no knowledge of the concept of the app to be tested. My teammates and I were able to recruit four other participants from the earlier survey that we used for the low-fidelity prototype. Important note, we did not conduct this new user test with any of the previous individuals tested. We conducted these usability tests via Zoom due to the SARS-CoV-2 pandemic.
The structure of the usability test was as followed: users were given tasks they had to complete in order for us to gain vital insight. We measured this on a scale from 1 - 3.
1 = Task was not able to be completed
2= Task Completed with Difficulty
3 = Task Completed Easily
Tasks users were told to complete:
-
explore the app and check out Tanya's profile
-
you're interested in Tanya, how would you indicate that?
-
start a conversation with Tanya
-
create an activity that you'd like to suggest to Tanya
Along with the user tasks, we as a team had goals that we wanted to gain insight on.
Goals we had as a team:
-
to make sure the navigation and event creation flow is clear, engaging, and easy to learn
-
to make sure each screens purpose was clear to the user
Key findings
-
80% liked the ability to scroll through matches
-
60% liked that the interests were included in the profile card
The usability tests provided us a healthy mix of results. These are the type of results that UX teams deem as vital. It allowed us to take the positive data, reinforce their placement and or experience within the app, and allow us to reiterate on the flow or elements that were less positive. For this product, we distinguished positive data as validation (meaning, we know that it works with users and those elements and or flows are solidified in the app), and negative data as areas of opportunity (things that we need to reiterate). The next and final step that the client needed from us was a final iteration of the mid-fidelity wireframes. We called these Iterated Wireframes.
.jpg)
The screens that were validated positively with users we kept the same for the most part, they did include enhanced UI elements. But we had to go back to the drawing board in regards to the create an event flow. One of the insights that one of our users mentioned stood out to us as something that we could explore. They suggested that it might be beneficial if the user could create an event in the messaging feature. The way we implemented it in our iterated wireframes is that if the user is messaging Tanya, they would have the option of creating an event right from the messaging screen.
This type of implementation could be done in a number of ways. Since we are working exclusively on the MVP version of the app, we needed to speak with our client about our thought process in regards to the create an event flow. The latest concept of the flow goes as followed. The user would be messaging with Tanya, and they would mention that they want to go on a hike on Saturday, the application would recognize that they are talking about a specific date and would on-screen recommend to the users that they create an event for that day. Machine learning would recognize that they are talking about hiking and would suggest that the user create a hiking event with Tanya for Saturday, right in the message screen. This implementation would require advanced software engineering, something the client might not have access to at the moment. With that consideration in mind, we added a Create an Event button at the top of any message so the user can create an event that way. These Create and Event screens were the main iterations we made post usability test.
Next Date!
After we handed over the iterated wireframes to the client, the designers' product scope was completed. The iterated wireframes, mid-fidelity wireframes, concept prototype, and other deliverables were handed to the client and their developers. The developers also have access to developer specific notes from us designers. This included element sizes, animation flows, and color HEX values.
Lessons learned
For the client, they were pleased with the design solutions that we provided. They mentioned that they valued the process that we took in creating the user experience for their app. They plan to launch the application in the next three months.
For me, this product represented the vitality of the design process. In today's UX world, a team can utilize a variety of methods when strategizing their product plans. Some are traditional (Design Think Process) and others nuanced (Agile UX). But what is essential in any process one might take is that everything must be centered around the user. They are our north star, and their insights that they provide are as crucial as the product conception itself. The digital products that win and survive are the ones that have considered all insight from the user and make design decisions based on research.