Fortuna 📗

I researched, designed, and implemented two features on the Fortuna mobile application during their beta launch in the App Store. Fortuna is a Stanford start-up and consumer-social platform using AI to create a better hiring/compensation process for students. It essentially acts as a "tinder" for searching for jobs.

Over the course of 6 weeks, I worked as a part-time design intern during winter quarter of 2021. My role for this project was to work with the product and product design team in order to implement two new, unique mobile features. These two features would address how students were able to express themselves beyond a resume in order to tailor for more relevant jobs.
‍

I conducted user research from Fortuna's initial design and converted my findings from over 60 interviews to develop two integrated features - soft skills and attributes in a bio section as well as the implementation of pre-recorded interviews.

The Opportunity

At the time, the below images are what the Beta Version of the app looked like. The team had already begun rolling out and designing the UI for the basic features of the app that should be included in the bio like name, description, age, location, etc. but were looking for someone, primarily an intern, to help introduce a new set of ideas to implement on the final product.

Again, the opportunity for me here was to implement two mobile features that would allow candidates to highlight and express themselves beyond a submitted resume.

User Research

The central questions that I asked myself were "how are students struggling to explain themselves beyond a resume?" "could it be a situation-specific problem?" and "how can a student distinguish themselves on the job market beyond their resume?". Upon initial discussion with the Fortuna team, we realized that this question entailed a multifaceted response.

Depending on the student or the situation, there were plenty of factors that influenced one's choice for choosing a job. So, in order to gain a better understanding of the scope of the problem, I began looking through current job searching platforms and listing personal pain points.

My two research goals were to 1) Understand what was frustrating about the current job search for students and 2) Understand what issues were the most pressing

Current Issues with Job Searching Platforms

As I was going through various job searching platforms and creating accounts, I realized that my experience with many current sites was impersonal. Beyond simply uploading a resume along with filling out information about myself such as skills, previous work experience, and school, there was really nowhere where I could express who I was beyond what the one-dimensional view of myself on paper.

Especially in an age where student's working and studying lives had been disrupted because of COVID-19, there were a lot of circumstances and situations that students didn't get a chance to explain. Of course there was always the option of writing an additional excerpt such as an essay, but this was untraditional and felt like a CV.

‍

Survey + Results

After doing my own personal research of sites on the current job market, I took charge in conducting university student data. Because a large portion of our use base consisted of college students, I conducted surveys from 13 different universities across the US. Highlighted below are some key insights from some of the students.

Because I am a student, I was in charge of researching ONLY the pain points of college students while the rest of the team covered other ages and requirements. The purpose of this step was to satisfy my first research goal. In an attempt to spread out the data that I was gathering, I took survey answers from students across the United States at 13 public and private universities including schools like San Jose State, the University of Virigina, and Rice.

I aimed to get around 7-10 responses per school, which left me at about 100 interviews total. I took a note of major, age, and location as compounding factors. However, what remained the same was the general frustration at how the application process seemed to not represent them as a person, and the interviewing process seemed to be arduous.

Some key quotes that I pulled from the survey are: “"There's no way for me to display my attributes and my customer service experience beyond what's on paper" and “"Scheduling and prepping for interviews takes up a lot of my time"

‍

I then condensed my findings by looking at key words that came up the most frequently in the survey.

Categorization using User Personas

I wanted to categorize my data and understand how I could address these problems for the applicant while concurrently addressing these problems for the employer. Thus, I grouped my survey results into goals, needs, and frustrations with two user personas taking the perspective of both an applicant and an employer.

My first user persona on the left is Sarah, who is an applicant. Sarah’s a 31-year-old administrative assistant who wants to switch jobs to spend more time with her daughter. She’s a fast learner and someone who can adapt to different work environments. Sarah is a single mother of a 2-year-old girl, and lack of time is a daily worry as she is currently paying for a babysitter. Sarah has goals like wanting to spend more time with her daughter and has frustrations like finding her attributes like customer service underrepresented.

My second user persona on the right is Jonathan, who is an employer. Jonathan runs his family’s grocery store full time, and with all his tasks like cleaning, cooking, and stocking, he can’t handle the additional responsibility of sorting through interviews though he really needs an extra hand. Jonathan has goals like reviewing job applications on his own time and finding applicants with the relevant skills and customer service background for his grocery store.

Prioritization

The team needed to prioritize the data because my design timeline was over the course of 5 weeks. Although there was a lot of great data to use and pain points to address, I was operating on a tight timeline and needed to implement features that were most relevant.

Consequently, to also make sure the implemented features were most relevant, I needed to find a way to create the most impact on my users. I could do this by narrowing down on what features were going to shift the usability and features of Fortuitous most drastically.

In order to figure out what pain points were the most relevant, the team devised a system for scoring each pain point. This was a way to rank the issues based on priority.

‍

‍

Ideation

The first issue that I noticed was that a lot of companies often ask for hard and technical skills, but lack in also adding a section for attributes. I viewed this as a very important topic to address not just because it was supported by my research, but also because it would allow for better value alignment between the employer and the applicant. It could also allow for more relevant jobs based on what sort of characteristics an employer would want to see in an applicant. This would concurrently solve an issue of relevance for both sides of the party.

So from our user persona Sarah “wanting to display her customer service skills” and Jonathan “streamlining more relevant applicants”. As a result, I would have hoped that it would result in a more pleasurable experience for the applicant and the employer after hiring.

Feature 1: Figuring out how to display what's beyond a resume

Brainstorm

I began with a brainstorming session to figure out the way that I would display the attributes feature. I started with looking at the Myers Briggs scale, where applicants could potential rank how comfortable they felt with a certain attribute. I then moved onto a thinking about more of a survey type scale, where applicants could answer questions and the app could automatically generate which of their attributes were the most apparent. My final idea was to create a visual system of selection with different personality traits, like the one shown with collars above. This is not pictured, but as an alternative and similar to the survey scale but WAY more abstract, I had thought about implementing something where, based on images or a specific selection by a user, they could have attributes generated.

‍

‍

Wireframes

The second step in the design process was to create wireframes for the attributes section. To play on my brainstorming, I built wireframes for the attributes as a selection option. Its pros were a clean looking design, but a con was figuring out the UI for selecting and deselecting. It could potentially affect the UI to the point of distaste for the user.
‍

I also built a wireframe for rating on a scale like the Myer Briggs brainstorm. Its pros were that applicants could be more specific about what specific attributes they’d like to work on or what strengths you really wanted to stand out to a company. Some potential cons were if people would actually rate themselves higher than they actually were, and it could potentially be a very long list.

Finally, I built a sliding system scale like the previous wireframe. A pro was that there was no specific box or scale to quantify your attributes. A potential con would be a more unpleasant UX and could fall into the category of additional work.

I eliminated the visual display because it could become too cluttered and it would be difficult to make icons to encompass all attributes

‍

‍

MidFi Specs

In order to refine the goals for the project and narrow a solution direction, I iterated on the design from the previous slide

Some of the changes that I made were:

• Getting rid of thee check mark and instead using a solid/not solid interface. This would make for a better UI and would make for easier implementation for the engineering team
• Condensing the layout of the attributes in order to make for more appealing UI

And this change made for my finalized design. This final design had benefits like a simple UI, giving applicants a way to display their skills beyond whats offered in their resume

• A satisfying selection system
• More relevant applicants and jobs
• And the alignment between applicant and company

Feature 2: Figure out how to upload a video resume

As a reminder from the priority list that was previously mentioned in the prioritization section, I wanted to address another way that applicants could express themselves other than what was expressed through their resume.

Again, because a lot of the survey responses indicated that applicants were having issues with expressing themselves beyond a resume on paper. I wanted to implement a feature that would navigate through this problem.

This could easily be solved through the implementation of a video resume where applicants could explain not only their past experiences, but what they learned and explain context surrounding the experience.

Wireframes

The first step again was wireframing. I had two initial ideas for what I wanted the pre-recorded interviews to look like.

The first being the submission of an audio recording

• Pro: Can record directly from phone, less storage space, eliminates the need for a special camera
• Con: Employers don't get to see your face

The second being the submission of an video recording

• Pro: Employers can see your face, more intimate and closely resembles an actual interview
• Con: May take up more bandwidth, hard to record professionally from a phone

MidFi Specs

After feedback from the product and product design team, I went with the video response factor. It was going to most resemble a traditional interview, and it would make sure applicants were really up for the job if they would be dedicated enough to record themselves.

The UI was approved, and I created the first prototype. To refine my goal of a video resume, I finished what I wanted the prototype of what recording the interview in app would look like. I did this by creating two versions of the video resume feature with a slight change in the UI, the play button.

Additional Features

I also added in two additional hints for the video resume feature to help guide a user through the process of recording in app or uploading directly from their camera roll.

Mobile Demo on App

‍

‍

Reflection

If I could go back to the start of the internship, I realize that there were a few things that I would change with how I approached this task

The first being to expand my research - My responses from the survey could have easily gotten bottlenecked because there possibly was not enough variation from what “students” represented. Because I was in charge of tracking student university data, I didn’t also consider trade school or students in apprenticeship programs who may have needed more specific features.

The second thing I would change is tracking and measuring favorability among features. If we weren’t running on a fast turnaround scale, I would have used A/B testing in order to conduct additional user research to understand what version of features a user would have preferred.

The third thing that I would change is the scale for scoring. Because we were running on such a fast turnaround schedule, the scale was hypothetical for our users and we weren’t able to measure the actual user feedback easily.

‍

‍

‍