Dragonfly

Problem Background  

According to Zippia, in 2021, it took an average of 21 to 80 job applications to land one job offer. Job hunting can be a number’s game – the more applications you submit, the higher your chances of landing your dream job. However, keeping track of every application you’ve submitted can be cumbersome as over 94% of users use multiple platforms to find prospective jobs. 

With over 78% of users using some form of organization tool to help them keep track of the positions they’ve applied to, an opportunity exists to congregate key attributes that are helpful for users to keep them organized during this process.

Research Insights & User Pain Points

Using our network, we identified a few different categories of prospective users and conducted over 60 survey respondents and heard the job hunting process would be easier if… 

• There was a way to keep all of their job applications organized
• They could keep job descriptions on hand without worrying about them being removed
• There was some type of automated process to keep my applications updated
• There was a way to keep track of what jobs need to be followed up on or when I last reached out to or spoke to someone at the company

Our preliminary user research with job seekers found that users were currently frustrated with the process of job hunting. Many found the process to be overwhelming and tiresome. The majority of our users are currently either Google Sheets/Microsoft Docs or Google Words/Microsoft Docs to keep track of their job applications. However, this process is typically abandoned due to the effort required to upkeep the data.

‍

Solution Explanation

“Based on our target users’ pain points and the capabilities of our team, we leveraged the RICE framework to prioritize the following features: 

Our learnings: RICE allowed us to easily see what was a priority and wasn’t based off distilling our user research and the capabilities of our team. 

In our MVP, we decided to prioritize our Dashboard. One deep exploration we made was on ‘extensions’. While it seemed extremely high-value for our users, it was initially high-risk for our technical team as none of the members on our team has ever built a feature like this before.

Once our SWEs conducted their research, we were able to conclude this was something attainable and something we pursue.

‍

Lo-fi Mockup

Hi-fi Mockups

Iterative Design Learnings

We conducted a total of 10 usability studies:

• Low Fidelity - 4 participants were tasked with managing the Card View and List View of our product as well as a possible chrome extension.
• High Fidelity - 4 participants walked through our polished designed product with prompts tasked at them using the Card View, Sort, Filter, and Board View.
• High Fidelity v.2 – 2 participants provided feedback on the newly updated version of the Board View

We learned the following: 

Low Fidelity: Users were able to navigate the Card View and List View easily. They bought into the idea of the product and really valued what the extension had to offer, that being a way to auto-populate new cards from job applications on the web. Additionally, they would like different ways to view the cards.

“It was very user-friendly! It’s nice to have options for the different views. I like that it  has the options for both auto and manual inputs which is nice.

High Fidelity: Users were excited about the potential of the product and liked the UI design overall. The tasks they found the most intuitive were creating cards, changing the grid layout, sorting, and filtering. Editing and adding cards to the Board View was far from intuitive and users felt lost and confused when it came to this process.

“I liked the Board View and would likely customize it as much as possible.”

High Fidelity v.2: The participants were able to navigate the website without any issues overall. The newly updated Board View was intuitive to use and users navigated the process seamlessly.

"I like it. It's a good way to have it all organized. It was straightforward and easy to use"

‍

Implementation Details

Where is it hosted? 

Dragonfly’s frontend is currently hosted on Netlify at this link and the backend is currently hosted on Heroku. The backend deployment may be subject to change due to Heroku Postgres going behind a paywall starting November 28th, 2022.

Dragonfly is built as a Web application using the JavaScript library of React. The idea was to create a database to host all information from users and display on the page all the info the user had pushed to the database.

What is your tech stack?‍

On the frontend we used the React library to build out the UX/UI while adhering to an Atomic design pattern. On the backend we used Knex.js to build out our backend schema, Node.js to build out an internal API for our app, and Postgres to store all the data we were collecting and utilizing throughout Dragonfly.

Some other technologies we used were JSON Web Tokens to authenticate and authorize users to access certain pages of Dragonfly, Bcrypt to hash users passwords in our Postgres Database, and Puppeteer to support webscraping from a LinkedIn job posting so users can automatically create cards in their dashboards.‍

High level journey of a request

Dragonfly's backend was developed using a Model, View, Controller architectural pattern.

What this means is that instead of having all the logic of a request inside of one large file, the request’s lifecycle is split between the model and controller, and then once the request is complete, the response from the request updates our view which is what our a users sees.

An example of this pattern in action can be demonstrated when a user attempts to automatically create a card using a URL from a LinkedIn job posting.

To start the request lifecycle a user would fill out a form including the link to the posting, the current status of the application, the date applied, the recruiter contract, and any notes they would want to attach to this card. Once all the information is filled in and the form is submitted, this submit event triggers a POST request to one of our API routes. All routes that handle CRUD operations specific to applications live inside of the applications controller. Inside of the applications controller there is an asynchronous function that gets called and pulls all the information from the body of the request.

Once the information is pulled, we can now pass in the parsed LinkedIn URL to our webscrapper which utilizes Puppeteer to run a headless browser and navigate to the URL provided by the user and scraps all relevant information from the posting (such as position, company, location, and job description). Once we have successfully scraped the information from the job posting we pass both the information from the body of the request and the scraped information to our applications model. Inside of the applications model is where the query is made to our database.

Once the query is completed we send a response back to the user with the information from the newly created row in our database, and with this response we can update the frontend to reflect the changes made to the database. 

What was the hardest part of development?

One of our technical challenges was the user authorization and how to keep the same user credential constant while navigating through different pages of our website.

Does your app have any scaling issues?

The scaling issues with Dragonfly can be broken down into two sections. One being the hard cap that Heroku sets on the free version of Heroku Postgres which is a limit of 10,000 rows for our database. If we need to store any more information than that, well we can't, not without paying a premium.

The other part would be the monolithic architecture of Dragonfly’s backend. Any small change to the schema, the controllers, or models requires an entire redeployment of the backend. This is a major bottleneck for our application as it is cumbersome to redeploy every time you make a change to the repo.

A monolithic architecture also makes it difficult to adopt any new technologies that might be well suited to address a particular function of our application.

Switching to a distributed system such a microservice based architecture can address some of these issues. With a microservice based architecture each microservice has a single responsibility. Whether it be signing up users and authenticating log in requests, or handling all the requests for users boards, these tasks are split up into their own microservice.

If we need to make changes to a microservice, instead of redeploying our entire backend, we only have to redeploy that single microservice. The technologies that the microservices utilizes can differ from one to another. This allows us to use technologies that are best suited for the responsibility of that microservice. 

What are some key takeaways?

Mark - I would say that a key takeaway is to spend a healthy amount of time to really think about and plan out the backend schema. By taking time in the beginning to plan out what the backend looks like, it can save you time later on because you won’t have to make lots of changes to it because all the support for the features you want to build out are all there and can be created using what you planned out.

Jairo - Building this product, I realized how the same result can be achieved using different paths and techniques. While developing the code, I would share my thoughts with my fellow developer on how to process the issue and he would solve the same issue with a different approach. This gave me the feeling that there is not right or wrong answer but maybe just concise and clean code, so at the end of the day both would have the same outcome

‍

Future Steps

We will continue advancing our project moving forward. We’d love to work towards other features we discovered were important to users but did not have the capacity to build over the course of this program (8-weeks). We look forward to sharing this with you!