6 weeks
UX Researcher (client facing)
5 Researchers
4 Designers
2 Product Strategists
1 Product Manager
At the height of the Great Resignation, Beela, a Swedish nonprofit helping women and nonbinary immigrants get into tech, asked Tech Fleet to help improve the way they served this community.
Millions around the world recalibrated their careers, but Beela stakeholders weren’t seeing enough growth or engagement. Several touchpoints—a podcast, mentorship, and a newsletter—weren't attracting new users.
Our task was to examine career changers’ experience with Beela and ideate concepts to improve the nonprofit’s services and convert more users to their mentorship program.
We created a dedicated Slack community with several channels, a way for new career changers to start comparing career paths, and a three-pronged feature on the home page giving users what they need at the beginning, middle, and end of their career transition journey.
Our work resulted in an extension and expansion of Tech Fleet's contract with Beela.
We ran six 1-week sprints, each with a different goal.
Before I joined the project, a Phase 1 Tech Fleet team set out to learn who makes up Beela’s community. Here are some of their findings:
The typical Beela user is a female immigrant to Sweden. She is highly educated, but not yet employed in tech. She thinks there are more opportunities in tech that don’t rely on Swedish language skills. Gender equity it important.
She’s moved to Sweden with a partner, and does not have children. Her Swedish is OK, but not great. This has resulted in career challenges, cultural barriers, and lack of a support system.
She’s interested in tech for personal fulfillment and job benefits. But she doesn’t know where to start, lacks industry knowledge, and has limited resources. She doubts herself and doesn’t feel like she belongs—in tech or in Sweden.
Beela shows up on her social media and seems interesting because of its mission and as a way to learn and make social connections. While she knows about some of the resources, she does not frequently use them.
We began Phase 2 by running an outcomes workshop with our client.
Why we did this: To focus our efforts on outcomes (increased revenue) rather than outputs (a new home page).
First, we met Beela stakeholders and asked them to work separately to note:
Next, we asked them to connect their priorities to the business outcomes those priorities would drive.
Then, we did a quick activity where the stakeholders:
The stakeholders prioritized REVENUE.
As a result of this workshop, I researched and presented potential nonprofit revenue models for Beela to consider. Different models rely to varying degrees on support from individuals, companies, governments, and former beneficiaries.
The unifying trait of the models?
Results.
What we learned: Beela is committed to providing free services to users. That meant they would need to base their fundraising on Key Performance Indicators (KPIs) such as placement rates, conversion rates, number of members and duration of membership.
Earning KPIs like these would allow Beela to make a more compelling case to potential donors.
In addition to a survey, Phase 1 conducted several interviews. We affinity mapped their findings, identified pain points, and turned them into business opportunities.
Why we did this: To keep users front and center in our process, to get alignment within our team about what we knew, and to communicate our work in a way that stakeholders would understand.
Each team member asynchronously affinity mapped the sticky notes from Phase 1. This allowed us to identify trends on our own before coming together to discuss. We all saw hot spots around finding community, getting support, and questions about how to start.
What we learned: Users have various goals and pain points around starting a new career, but those goals overlapped at a high level.
There were big trends around:
While affinity mapping helped identify trends in research findings, it didn’t put those trends within a business context. We did this by using the Opportunity Solution Tree (OST) framework to filter goals and opportunities through user needs.
Why we did this: To spend our time on work that would have significant user impact in problem areas Beela was most prepared to address.
The main user need that Beela serves is the root of this tree: career transitioners want to find a job in tech. The subsequent levels of branches are distinct opportunity areas that help users meet that goal, each with its own set of supporting opportunities.
We identified 5 distinct opportunity areas from the Phase 1 research:
We asked the Beela stakeholders to help us prioritize these opportunities. We asked them to think about which branches they currently address and which would have the greatest impact.
They prioritized:
What we learned: Many Beela users are at the beginning stages of their career transition. We needed to meet users at the start of the journey and help orient them to the world of tech and boost their confidence.
We followed Google Design Sprint methodology to develop a high-level service blueprint. To do this, we mapped a basic customer journey, brainstormed, sketched potential solutions, and voted on ideas.
Why we did this: Originally, our goal for the week was to create a testable prototype. As we sketched solutions, we found that a service blueprint was a better deliverable than a prototype at this stage.
First, we created a bunch of “How Might We…” questions and grouped similar stickies. 12 distinct categories emerged. We voted first on what we thought was the most important theme to focus on, and then on the most important question within that theme to arrive at our design challenge:
How might we provide differentiated resources to users depending on their needs or stage of career transition?
With a design challenge identified, we created a (really) rough journey map of a simple use case.
We highlighted what we thought was the most important step in the process for us to work on (find ways to engage or absorb information).
We tackled this design challenge asynchronously in two meetups based on team availability. To structure our time, we used the 6-1-1 model.
My sketches showed users the stages of transition. I imagined the resources for each stage contained in each section. I used strategies like a progress bar, a checklist, and navigation tabs to allow users to see the right information at each stage.
As we talked through our sketches, we took notes on the UI components we described. Despite very different layouts, the team had several different versions of visualized steps of the transition journey, breaking up the scary career transition journey into manageable steps.
Having alignment on visualized steps to a career in tech allowed us to zoom out and think about a Customer Journey Map. We believed this would give us the clarity we needed about what resources a user could need at each step of their journey.
What we learned: We had a hard time getting aligned as a team in this sprint. In retrospect, our design question was a little too vague and our rough journey map at the beginning of the week wasn’t quite specific enough, either. Even so, we learned to break the Google Design Sprint framework in a way that helped move us forward.
Failing to meet our goal of creating a testable prototype also taught us to move forward aggressively in the following sprints.
With a working customer journey in place, we broke into 2 teams. This ended up being a very good choice and provided a solution that would not have occurred to us otherwise.
Why we did this: We were still keeping our options open, so we tackled the other prioritized branches of the Opportunity Solution Tree. We didn’t want to get too invested in a single solution.
I want someone
Supporting me
through this
transition
emotionally
I need help
choosing
a career path
in tech
The Emotional Support team thought meet-ups, networking events, and webinars would be a good place to start. This would allow users to develop relationships, increase their networks, and give them a sense that they belonged to the tech community.
My team, the Career Path team, helped users understand the different paths available to them within tech. To do this, we:
Mapped a possible user journey, noting our assumptions along the way
Charted our assumptions on a 2x2 matrix on axes representing importance and strength of evidence
Sketched and annotated solutions asynchronously
We saw a strong trend towards the Slack solution:
...and away from the idea of events:
Users at different stages of the transition had different interests:
Users did not always take the steps in the order we expected:
We were beginning to understand that each team's solutions were not only connected, but relied on each other to work successfully.
The Emotional Support team needed to create a space where users could feel comfortable starting their career transition journey.
The Career Path team needed to make the transition seem more attainable and start users off with an easy step, say, joining Beela's Slack.
To incorporate the new data into our solutions, we updated Provisional Personas and created storyboards as we iterated our ideas
The Emotional Support team pivoted their solution from events to a Slack community.
The Career Path team updated their 5-step path to a simpler 3-step path based on interview data. To test our iterations, we conducted 3 user interviews with updated prototypes.
Why we did this: Interview data suggested we needed to update our solutions. After iterating, we wanted to mitigate risk by testing again.
I updated personas to reflect new interview data:
Bia is a recent UX bootcamp grad.
She’s somewhat familiar with the field thanks to her bootcamp, but still has a lot to learn. While optimistic, she has plenty of “now what?” moments that feel like dead ends.
Judy landed a job 3 months ago.
Imposter syndrome still rears its head, though. She wants to find a way to gain experience outside the workplace in an environment that will allow her to boost her confidence through helping others.
I wrote copy for stories about the existing Beela experience and the Career Path team’s solution.
The existing storyboard shows users trying to navigate the career transition process by seraching online and trying to figure it out themselves:
The Career Path solution storyboard shows what happens when Beela anticipates users' needs and provides tools to help users decide on a career path and give them the right information at the right time:
Before we passed our work onto Phase 3, we inserted our solutions into a mid-fidelity version of Beela’s home page and ran two usability tests.
Why we did this: We wanted to see if our solutions would stand up in context and gather as much information as possible to pass on to Phase 3.
The first part of our solution encouraged the absolute beginner who is curious about the various roles in tech. The career paths that Beela supports—everything from Software Development to Data Science to UX Design—will live here.
The Career Path team consolidated the number of steps in the previous Sprint’s prototype from five steps to three steps. In this section, users can take the appropriate action based on where they are in the journey:
The Emotional Support team added their Slack solution into the Programmes and Activities section.
We tested these updated solutions with two users. In these tests, we observed different behaviors. One users was expecting to find imagery on the site prototype that could guide her towards important information. The other read every word diligently. Both perked up when they arrived at our content and suggested that we move it higher up the page.
Before parting ways, we made the following suggestions to the Beela Team: