Helping users meet face-to-face — Lighthouse | A UX Case Study
“I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.”- Maya Angelou
Humans crave belonging: being able to identify with others, form relationships, be a part of the group. At one time, belonging to a group was essential to human survival. And if you recall any part of high school, you’ll know it is still hard-wired into our behavior today.
In recent years, the Fear of Missing Out, or FOMO, has gained traction in media discussions. Apps like Instagram and Snapchat provide you with a never-ending stream of your friends’ parties and vacations. This constant bombardment of images and quotes from events you’ve missed can lead to feelings of being left out and overlooked.
Objective — Create an events-based app
The goal of our project was to address the fear of missing out through an events-based app. Users needed to be able to mark their locations and automatically invite their friends to join them.
I led a cross-functional team of two developers and three UX designers. In three weeks, we needed to design and build a mobile iOS app that would allow users to create events, add friends, and share locations.
Charting a course
Communication is critical on a team. To help, we established a collaborative decision making process. Whole-team consensus was the goal, but two votes out of three could carry a decision. If our developers needed changes, a minimum of two designers had to be involved in the discussion. All decisions were documented in a shared file. In the event of a dispute, it was my responsibility as Team Lead to make a decision and move the team forward.
I held daily design scrum meetings to prioritize the day’s work. These were followed by whole team standup meetings with our developers. As a group, we set a project timeline with milestones and handoffs.
Involving the developers from day one was incredibly helpful. They provided immediate feedback on the feasibility of our designs and volunteered useful ideas of their own.
Research —Gathering data
Given our limited timeline, we jumped immediately into Agile UX Design. After listing our assumptions, we built a research plan to address the gaps in our knowledge.
Surveys & Interviews
Using surveys and contextual interviews with individuals between the ages of 18–35, we quickly discovered two important points.
Discovery 01 — Our primary audience has a much narrower age margin than anticipated.
Our data revealed a huge difference in motivations between individuals aged 18-25 yrs and individuals aged 25–35 yrs. 18–25 year olds expressed 100% interest in a tool that would allow them to broadcast their location to their friends. 25–35 year olds expressed exactly 0% interest. From this, we narrowed our scope to individuals ages 18–25, with a concentration on college students.
Discovery 02– 18 to 25 year olds are primarily motivated by relationships.
25–35 year olds are more often motivated to go out based on the type of event happening. They arrange their plans ahead of time and prefer to invite specific friends instead of sending out a general invitation to all their friends.
18–25 year olds differ drastically. As young adults, they are often newly independent and focused on making and maintaining new relationships. When selecting activities, they base their decisions first on who is going to the event rather than what type of event it is. They prefer to go out with known friends and are unlikely to go to an event without knowing at least one other person there.
This data contradicted the original project assumption that the app should be events-based. We realized that knowing which of their friends were there, — that was the primary motivator for our users.
Our User
Competitor Analysis
Competitor benchmark testing on Foursquare revealed that speed of use is especially important to our users in two ways. Users want to (1) quickly scan which of their friends are available to meet up, and (2) connect with those friends as fast as possible. Our product would need clear hierarchy, clean design and friendly copy to help them accomplish that goal.
Define
The MVP: find friends | bring friends to you
We created a story map for the user’s journey through our product. The key tasks users needed to be able to accomplish were:
- Find and view friends on the map
- Invite friends to your location
To do this, users had to be able to add friends and then find them again in the friends list or on the map. They also needed to be able to mark their location and start- or stop- sharing that location at will.
Privacy
As the user’s advocate, I had some major concerns about privacy. How were we going to protect users’ location information from misuse? What about stalking situations or burglary?
Our limited timeline and project constraints prevented us from implementing all the solutions we came up with, however we were able to put in some layers of defense beyond the Terms & Conditions agreements.
First Layer of Defense — Controlling Your Friends
- Users are listed by their first and last names. Paired with a profile photo, this helps them verify their identity.
- Users can accept or dismiss friend requests.
- Users can remove friends from their Friends’ List at any time.
Second Layer of Defense — Selecting Who Can View Your Location
- When dropping a pin, users must choose which friends to invite to their pinned location. Only invited friends are able to view the user’s location.
Ideate, prototype, test
We started building wireframes and conducting initial usability testing. Feedback from these tests helped refine the app in general, but our onboarding in particular needed work.
Onboarding — Balancing time, permissions and asks
We had two hurdles to get over in the onboarding experience: timing and creating an account.
We changed the onboarding flow numerous times to balance an engaging experience with the time the app needed to call the correct location map. Initially, we had a launch screen, followed by a location permissions request. Eight seconds into the first usability test, we realized our error.
Although our app was targeted at digital natives, we still needed to prime them to accept the location request. Users immediately stopped at the permissions request saying, “I don’t even know what the app does yet.”
We added a screen explaining what the app does, and a coachmark to encourage them to allow location permissions. We tested again, but feedback showed the request was still too soon.
Next, we expanded and split up the onboarding to meet the timing needs of the app while still giving users more information. A short 3-screen tour after launch showcased the top features of the app. Pre-permissions copy clarified why users want to allow location tracking. Strategic button placement primed them to select the correct option.
Introducing “create an account”
Originally, after allowing location tracking, users were sent to setting up an account. In testing, this again proved too soon. Having a second ask immediately after asking for location tracking stretched user engagement to the point of breaking. They needed more — both time and value.
We adjusted and had users land on a global heatmap from location permissions. From here, they would be able to see nearby hot spots — areas where the most Lighthouse users were hanging out and dropping pins. However, in order to drop their own pins and find friends, they would have to sign up.
Satisfied we had resolved our flow issues, we tested again. The onboarding part went much better (with the minor exception that no one actually read any copy). Then, our devs came back with some unfortunate news — the global heatmap wouldn’t be ready in time for launch, it would have to come out.
Back to the drawing board.
Adjusting to new constraints
How could we space out the requests for information while still keeping the user engaged in the process? We no longer had a heatmap, what else could we do that would provide value and an opportunity for interaction?
Throughout the app, we used a drawer to display important, relevant information. In testing, users often missed the drawer completely or did not realize it was moveable.
We replaced the global heatmap with a map screen with the simple coachmark “swipe up to get started.” When users swiped up, the drawer was raised and users could see the sign up call-to-action (CTA). This began the learnable pattern of finding important information in the drawer. We reinforced this pattern with an “Add Friends” CTA in the drawer after creating a profile. In the logged-in map view, the drawer allows users to view and access a full list of their friends and invites.
Worried that onboarding had become too long, we tested again. But, users swiped through the tour and tapped through the permissions in seconds.
Why did this work?
Users were now moving through onboarding so fast, they were only absorbing a word or two before reaching the permissions request. Interestingly, although they weren’t reading all the words, they were now much more likely to allow location access. Why?
When those screens weren’t there, users shied away from granting permission. Having those screens, and the choice to ignore them, gives users a sense of control.
The repetitive micro-interactions build users’ confidence in their ability to navigate the app. The onboarding tour creates a pause that allows users to get used to this new environment. As a result, they are more willing to allow us to use their location and sign up for an account.
Clean and scannable interface design
We created a style guide that emphasized a clean, scannable look. This would help users accomplish their tasks quickly.
Lighthouse is a fun, energetic app. Orange’s connections with energy, vitality and youth made it a perfect primary color. We used it throughout the app to call attention to CTAs and clickable content.
Early on, we had a dark blue as a secondary color to draw on the idea of water and light (lighthouse). We soon discovered that the hues we had chosen were competing with one another because they carried the same visual weight. We dropped the blue in favor of maintaining a light look with more white space.
Dropping blue also helped us address some accessibility concerns we had. We used Stark, a Sketch plugin, to simulate what our designs would look like seen through various types of color-blindness.
Color alone wasn’t enough to differentiate between active and inactive states. We employed size, weight and other visual clues to help distinguish changes in state. Different icons and sizes help users identify their pin from their friends’ locations.
Summary
Lighthouse is a friends-based app that allows you to find your friends’ current locations, drop a pin in your location and automatically invite your friends to join you.
“People first” was the main theme for both the final product and the process of creating this app.
Emphasizing friends and relationships in the product design was key for our primary audience. We gave users multiple paths to adding and finding friends. We kept the design clean and light to allow users to scan quickly and find their friends.
I worked hard to create a strong culture of “people first” within our team. We worked closely with our developers, sharing desk space and taking them on the user journey with us. As a team, we produced better designs and a better product by creating a supportive environment.
The developers saved us more than once from wasting valuable time heading down the wrong path. In turn, they became more deeply invested in the product and its design. They had a clearer idea of where we were heading and were able to build the right product out the first time. The product, and the people, benefitted.
Please reach out to me with any questions you may have about Lighthouse! I can be found on LinkedIn or at shathaway.ux@gmail.com.
Download Lighthouse from the app store today!
