A sample question from the onboarding flow, which collects data on things like the user's sexual, gender, and ethnic identities.
Content Design
Thrive Out Loud is a 100% LGBTQIA+ professional mentorship platform. It aims to create a safe space where queer young adults can find career guidance from mentors who understand their unique challenges and perspectives.
Thrive Out Loud’s users have profile pages where they share their personal and professional backgrounds. These pages are an important tool for both mentors and mentees to self-assess potential compatibility before moving to the next stage and setting up a first meeting.
Importantly, the information displayed on the profile pages falls into two categories:
Our team was tasked with re-looking at the designs for the profile pages. While doing so we asked ourselves:
How might we balance the onboarding information with the supplementary information to make profile completion as pleasant and easy as possible?
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.
3 weeks.
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.
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. This meant we were building on three previous phases’ worth of work, inheriting user flows and screens from previous teams who were no long with the project. Documentation was often patchy. We iterated upon this previous work over four 2-week sprints, one and a half of which was focused on the profiles.
Thrive Out Loud’s core values include creating a safe, inclusive space where users can be themselves and obtain empathetic mentorship. Finding the right fit between mentors and mentees is crucial to making this a reality.
Because of this, a central piece of the platform is its matching system, which relies on user information to suggest compatible mentor-mentee matches. Data points include the users’ professional backgrounds, and other details like their sexual, gender, and ethnic identities.
This information is stored in a database to be read by the platform’s matching system. Yet, it is not only relevant to the machine. Our human users also need access to this information so they can get to know each other before establishing further contact. This means the data also needs to be displayed publicly on users’ profiles.
When we joined the project, a sign up flow had already been designed to include a series of onboarding questions to collect the matching data. This put us in an interesting position as we got into work on the profiles: the user had already done the work of inputting much of their profile content before they ever saw it.
A sample question from the onboarding flow, which collects data on things like the user's sexual, gender, and ethnic identities.
We needed to think carefully about how to manage this. We did not want to put the user through the tedium of having to re-enter their personal details when it came time to fill out their profile. There were also concerns from the data management perspective. The matching system’s data needs to be clean—what’s held in the system’s backend must exactly match what’s on the user’s profile.
Because of this, it was decided that the app should import the user’s onboarding information into their profile on their behalf. This would leave them with a draft, semi-complete profile. They would then have a chance to review, edit, and add to this draft, including filling out the additional content buckets that are not collected during onboarding.
How best to communicate with the user so that they would understand the semi-complete status and be guided through profile completion became a central challenge in this project.
We had a few guardrails that helped guide our work:
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. Right off the bat, we wanted to prioritize the user’s sense of safety and control. They should 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.
CTA exploration: draft mode, with preview and publish CTAs.
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, adding unnecessary confusion and friction.
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 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.
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.
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.
The “publish” banner we introduced does a lot of heaving lifting to make the users feel in control of their information, and to communicate with the user about the status of their profile.
However, we still needed to find the right way to guide the user through the next steps of completing their profile. 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.
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. Through low-fi user testing, we learned 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.)
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.
Users found this implementation much clearer. They quickly understood what we were communicating, and that there were additional content buckets they could fill out. They were also able to understand how their profile would look to others.
The banner, publish button, and dynamic prompts work in tandem to create a thoughtful and intuitive user experience that is centered on establishing trust with 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.
This integration of features not only enhances the user experience but also aligns with Thrive Out Loud’s commitment to user safety and empowerment.
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 remove friction during account creation, and 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.