Content Design

Thrive Out Loud Profiles

Using dynamic prompts to help users control their profile content.

Thrive Out Loud needed to make sure its users were correctly filling out their profiles. Our team created a system of dynamic prompts to guide them through the process. 

Role

I worked as the UX writing team lead with two other UX writers. This case study was written in partnership with one of them, the fantastic Marissa Goodman.

Duration

3 weeks.

Constraints

A short timeline / uneven project history / working in a volunteer setting / lack of capacity for input from the design team / lack of over-arching project oversight.

Context

Thrive Out Loud is a Tech Fleet project. Tech Fleet is a not-for-profit dedicated to creating opportunities for people to gain real-world tech experience. They partner with other not-for-profits seeking tech solutions and put together teams of volunteers to deliver them. I joined Thrive Out Loud during the project’s fourth phase.

Project Background

Thrive Out Loud is a LGBTQ+ professional mentorship platform. It prioritizes creating a safe, inclusive space where mentees can create meaningful connections with mentors like them.

A matching system suggests connections based on compatibility. It pulls from data points including professional backgrounds and personal details like sexual, gender, and ethnic identities. Users answer a questionnaire during sign up to provide this information. 

An image of one of the onboarding questions. Text onscreen reads "What is your gender identity? Your gender identity will be displayed on your profile to help mentees with similar identities find you. We won't share your personal information with anyone else."

A sample question from the onboarding flow, which collects data on things like the user's sexual, gender, and ethnic identities.

This data also appears on their profiles. It sits alongside other information, like long-form bios, that the user inputs after sign-up. 

Navigating users through completing their profiles proved to be a challenge. How should the information they provided during sign up be balanced with the new content they would be asked to add? How could we ensure users understood info had been pulled from onboarding? How could we make it sure that there were more sections to fill out?

Goals & Objectives

Research

Past user research was available, providing target audience insights:

Privacy, safety, and control were identified as  important when it came to user's personal information.

We also looked at other profile creators, like from ADP List and LinkedIn, to understand common patterns.

Strategy & Approach

Based on user research, we knew we had to prioritize the user's sense of safety. This meant that the user would understand how their information was being shared with others on the platform. Ensuring the user knew what their profile looked like to others became important.

Solution 1: Edit & Publish Banner

When a new user arrives on their profile for the first time, they see the draft profile the app has compiled for them based on their onboarding answers. We needed to find a way for them to understand that their profile still needs to be edited, and is not yet viewable to the public at this stage.

Our first approach to addressing this was exploring “preview”, “publish” and “edit” CTAs.

A screenshot depicting "Preview" and "Publish" buttons at the top righthand corner of the profile page.

CTA exploration: draft mode, with preview and publish CTAs.

A screenshot depicting "Edit" and "Publish" buttons at the top righthand corner of the profile page.

CTA exploration: preview mode, with edit and publish CTAs.

We quickly ran into the issues with this approach. The profile design makes use of editing pop up modals, each of which has a “save” CTA. In pressing this “save” CTA, the user could reasonably expect that their edits be permanently saved. The addition of a “publish” button complicated this, possibly resulting in lost edits.

The About me editing modal, which allows the user to input gender identity, sexual orientation, ethnic background, languages, and hobbies and interests. A "Save" button is included at the bottom right.

Users add content to their profile with pop up modals, which include a "Save" button.

So, we pushed to find a simpler solution.

We conducted a competitive analysis to understand how similar platforms guide their users. LinkedIn uses editing modals, like we do, without requiring any additional action from users beyond clicking the edit icon on a section. ADP List also uses an editing modal, along with an ‘edit profile’ CTA at the top. Both approaches had a simplicity we wanted to incorporate into our design. We concluded that a “Publish” button would add unnecessary complication.

Examples of editing modals from both LinkedIn and ADPList.

Left: LinkedIn profile editing modal; Right: ADPList profile editing modal

After careful thought, we landed on a new solution: a temporary banner at the top of the page. The banner contextualizes the “Publish” CTA, and provides an opportunity to communicate with the user about the draft status of their profile.

A depiction of a banner across the top of the profile page which reads "Your profile is not public. We started your profile based on the info you gave us during signup. Finish filling it out, then hit publish to make yourself visible to mentors." A "Publish" button is also included.

The banner we introduced, displayed at the top of new, draft profiles. It includes a "Publish" button and an explanation of the profile's status.

‍This banner ensures our users clearly understand the status of their profile, and what they should do next. It introduces a little bit of positive friction, making sure our users stop and review what's been generated for them. This, in turn, reinforces a sense of safety, ensuring the user feels in control of their information.

Solution 2: Dynamic Prompts

The “publish” banner we introduced does a lot of heaving lifting in inviting users to add to their profile. However, we still needed to find the right way to guide the user through the next steps. Whatever solution we landed on would need to balance the two types of profile content: 

In the beginning, we tried displaying the empty supplementary content buckets in-line with the pre-filled ones. Placeholder copy was used to prompt the user to fill them out. This approach relied mostly on visual clues to separate the types of content.

The About me section from the profile page. The "Interests" subsection is highlighted in purple and accompanied by an edit icon to indicate that it has not been filled out.

An example of an earlier solution, which used placeholder copy and visual cues to indicate the empty “Interests” section.

We quickly realized that this approach wasn’t working. Some quick user testing taught us that it simply wasn’t clear enough. Users found it confusing; they failed to quickly understand that the section highlighted in purple was a new content bucket that they could add to. 

The solution above also created what we came to think of as “the preview problem”: a logged in user would see the empty sections on their own profile; every other user would not. This made it difficult for users to see an accurate preview of their public profile, which was one of our guardrails.

So we went back to the drawing board, asking ourselves how we might clearly prompt the user to fill empty sections while giving them an approximation of their public profile.

Ultimately, we landed on a more content-driven approach. We implemented clear, language-based prompts that speak directly to the user, telling them in plain language that there are additional sections they can fill out. For example, “Add to your profile by sharing your interests.” These prompts are displayed in small banners at the top of each profile section, rather than in-line with the profile content.

The prompts are dynamic, changing depending on which content buckets are empty. In the About me section shown in the example below, you can see the prompt cycling through various versions, changing to include gender identity, sexual orientation, race and ethnic background, and interests, depending on what info the user has provided. (Note: some of this—gender identity, sexual orientation, race and ethnic background—is onboarding information, but could still appear here if the user chose “Prefer not to respond” while signing up.) 

An animated gif of the About me profile section. A banner below the headline changes dynamically to reflect empty sections. Banner reads "Add to your profile by sharing your interests."

A prompt box at the top of each section dynamically reflects empty sections in the user’s profile. Empty sections are not displayed.

Importantly, empty content buckets are not displayed with this solution. Placeholders are no longer necessary. This gives the user a much closer approximation of their public profile. With the exception of the prompt banner, they see what others see.

The Finished Profile

The banner, publish button, and dynamic prompts work in tandem to create a thoughtful and intuitive user experience that is centered on creating a safe space for Thrive Out Loud users. They can confidently and easily complete and publish their profiles, knowing exactly what information is being shared and when. It is also easy for the user to understand how their profile will look to others, and what additional content buckets they have the opportunity to fill out.

Final Thoughts

Coming into a project in the middle can drastically impact the way you think about it. You take the logic the project is built upon for granted, assuming it’s sound.

However, after thinking deeply about the relationship between onboarding, the matching system, and the profiles, I’ve concluded that the existing structure is perhaps needlessly complicated. If I could do it all again, knowing what I know now, I would suggest scrapping the onboarding questions altogether. A simpler, more elegant solution would be to allow users to sign up with a quick account creation, then use the profiles to collect matching data. 

This would make it faster and easier to sign up. It would also eliminate the need for pre-filled draft profiles and the dynamic prompts and banners we engineered as a solution to explain them. It would likely also make development faster and easier, as it would reduce the amount of screens that need to be developed and maintained.

In short, we spent a lot of time finding a solution for a problem that could have been eliminated altogether.

That being said, given our short timeline and the reality of coming into the project midway through, I believe we did the best we could with our circumstances. The solutions we implemented address all of our goals and provide a clear, intuitive user experience.