myFlix Project

Overview

myFlix is a web application developed using the MERN stack (MongoDB, Express, React, Node.js). It provides users with information about movies, directors, and genres, along with the ability to create accounts, update their profiles, and maintain a personalized list of favorite movies.

Purpose & Context

This project was part of my CareerFoundry web development course, designed to demonstrate my abilities in full-stack JavaScript development. The goal was to create a dynamic, user-focused application that highlights my technical skills and problem-solving abilities.

Objective

The primary aim was to develop both the server-side and client-side of the application. This ambitious project was intended to showcase my capabilities in full-stack development while solving the challenge of integrating various features into a cohesive application.

Approach

Server-Side

• Built a RESTful API using Node.js and Express.

• Designed and implemented CRUD operations to interact with a MongoDB database, providing JSON-formatted responses.

• Secured the API with JWT-based authentication and authorization mechanisms.

• Extensively tested endpoints with Postman to ensure functionality and reliability.

Client-Side

• Developed a responsive, single-page application using React and React-Bootstrap.

• Designed multiple user-friendly views:

• Main View: Displays a list of all movies with a search feature to find a movie by title..

• Movie Detail View: Shows details about a single movie with options to add or remove it from the favorites list.

• Login View: Enables user authentication.

• Registration View: Allows new users to create accounts.

• Profile View: Lets users update personal details and manage their favorite movies.

• Implemented state management using React Hooks for cleaner and more maintainable code.

Challenges & Key Learnings

1. Data Flow and Component Architecture in React

The Challenge: Initially, structuring the flow of data between parent and child components led to unexpected rendering and state update issues. The complexity came from juggling multiple views (e.g., Main View, Movie Detail View, and Profile View) that each needed data from the API in slightly different formats.

How I Addressed It:

• Discussed debugging and problem-solving strategies with my tutor..

• Used the React Developer Tools to trace the state and props flow in real time.

• Restructured components so that data fetching occurred at a higher-level parent component, reducing repeated network calls and ensuring consistent data availability.

What I Learned:

• The importance of having a clear “data flow map” that shows which components own particular pieces of state.

• How to leverage React Hooks (mainly useState and useEffect) more effectively to manage and propagate data.

1. Integrating Authentication and Authorization

The Challenge: Incorporating JWT-based authentication was my first time handling secure routes in a React application while using a custom-built Node/Express API. Ensuring token validity, handling token expirations, and differentiating between authorized/unauthorized states required a cohesive strategy across both client and server.

How I Addressed It:

• Studied official Express and JSON Web Token documentation, experimenting with token-based middleware to validate user sessions on the server side.

• Created a higher-order component (HOC) on the client side to guard certain routes, ensuring only authenticated users could access them.

• Implemented robust error handling and user notifications to improve the user experience around login/logout states.

What I Learned:

• Best practices around storing JWTs (e.g., avoiding localStorage if possible) to mitigate security vulnerabilities.

• The value of clear error messages and redirection strategies to maintain good UX when a token is invalid or expired.

Duration

Completing the project took significantly longer than other assignments due to the complexity of full-stack development. The server-side was completed within a few weeks, but the client-side required additional time to fine-tune features, enhance responsiveness, and troubleshoot challenges.

Screenranker

The Proposal

Screenranker is an e-commerce platform for creators to sell the screen rights to their intellectual property. Adapted IP is increasing in popularity, proven to be a better/safer ROI for producers, and there is yet to be a robust ecommerce solution that helps facilitate sale and search of this type of content. The founders are entertainment industry professionals who believe that this is the natural next step in content acquisition.

Key objective

Screenranker is going be the first ecommerce marketplace for Intellectual Property. This includes the sale of rights or ownership to any of the following: Books, Podcasts, Stage Plays, Documentaries, Video Games, Merchandise and Journalism.

The organization’s goal is to have a fully responsive website released by the end of Q4 in 2023.

The product suite must include responsive designs for their onboarding flow, home page, search results page and a product page displaying the individual IP.

Solution

Working with the founders and a technical team, I researched and designed a full e-commerce platform for acquiring intellectual property.

Design Process

• Research & Synthesis

• Architecture & UX Design

• UI Design & Prototyping

• Testing & Handoff

  
  

Research

The first step in our research was coming up with our goals.

• Is buying/selling intellectual property a problem for for those trying to do it?

• How does the process work for most people?

• What works well and what does not work about the process of acquiring IP?

• What information is needed for buyers to make the right decisions?

Market Research findings

• The market for IP has recently undergone a radical shift. While in previous decades the buyers for IP were generally limited to the major studios that number has gone up dramatically with the proliferation of streaming services, production companies and smaller independent studios.

• While more movies are not necessarily getting made, the amount of IP being purchased or optioned has increased dramatically.

• Adapted IP is increasing in popularity, proven to be a better/safer ROI for producers, and there is yet to be a robust ecommerce solution that helps facilitate sale and search of this type of content.

• The Blacklist, which is a website where screenwriters pay to post their original scripts online, has become enormously successful. This is despite the finding that most original scripts are a far less valuable commodity than known IP. Producers see IP as content with a built-in market while making a film based on an original film is far more of a gamble.

• On the seller side, we found that creators ultimate goals are to have their work adapted. Very few books or other content make very much money but if their work can be adapted they are paid from that and given more exposure.

Competitive analysis

Key Takeaways

• As of now there is no central location for selling intellectual property. Publisher’s Marketplace seems to be the most popular but advertising IP is mostly decentralized among social media and scattered marketplaces.

• Most sites for advertising IP are medium specific and books are the only type of medium with any existing infrastructure. Meaning booksellers advertise in one place, other artists mostly tend to advertise their work through social media. While books have historically been the main source of stories for film and TV recently podcasts, video games and other types have launched successful franchises.

• Existing marketing sites are not tailored to how people in the film industry search for IP to adapt. They do not have sophisticated search features that would allow for buyers to search for themes, or types of roles for actors to play. We found in our research with industry types that these are the most important factors in how they look for IP to adapt.

Primary Research

Surveys

We sent surveys to 1,200 people in the publishing industry, 1,000 people in the entertainment industry and 400 people involved in work in other mediums.

User Interviews

We recruited users from our email surveys for more in-depth discussions of the process of buying and selling IP. We spoke with seven people from the publishing industry and eight people from the entertainment industry. They were between the ages of 28 and 53.

Personas

Using the information we gathered from our surveys and user interviews we created personas of our most likely buyers and sellers of IP. They are used exclusively using quotes from the interviews or surveys. The persona types were created based on matrices of profession and status. We were focused on recruiting “Hard users” so we wanted be able to identify the needs of high level creators and entertainment industry professionals but also mid-tier users as well.

We created personas for high and mid-tier producers, screenwriters and actors as well as best-selling authors and published authors who had not written a best seller.

Goals

Creator Goals

• Show off their work to the right entertainment industry professional who will be able to get their work adapted.

• Be able to field multiple offers to option their work.

• Make money.

Industry Professional Goals

• Be able to quickly search through quality material for something they will be passionate about making.

• Quickly find work with specific story elements like “Female Lead”, ‘Horror/Sci-Fi” or “Mistaken Identity”.

• Find material beyond books to adapt.

Business Goals

• Become the leading marketplace for intellectual property.

• Create first-class branding and UI to position ourselves as the best in class.

• Quickly grow roster of creators to make the marketplace appealing to industry professionals.

Architecture

Based on the goals gleaned from our interviews and personas we began mapping out how the most important goals would be accomplished. The entertainment industry professionals did require a lot of information before making a decision. We wanted the process for creators (our paying customers) to be as simple as possible so we had to make some cuts from what was asked for.

Feature Set

Once we had the user and business goals in place and before we began designing we worked with our technical team to devise a feature set which would address all the goals we had in place on each page.

Screenranker Feature Set

Wireframes

We created wireframes to help us test out different versions/iterations before moving on to the visual design.

Usability testing

We conducted three rounds of usability testing focusing on the onboarding process which is the most complex part of the site. The initial areas where users had difficulty getting through the flow was mainly on the Plot/Theme page with our design for picking multiple genres and tags to add to their work. In the first round only one participant out of five was able to easily complete the task while three had some diffficulty and one could not complete it. After some redesign and several more rounds of testing we had a session where four out of five participants were able to get through it easily and one completed it with some difficulty.

UI Designs

UI Kit

Final UI Designs

Next Steps

Screenranker is due to launch in Q3 of 2023. Some of the next steps will be adding important features like a recommendation engine that was not deemed feasible for the time constraints.

On launch, the most important KPIs to track are:

• Conversion rate through the onboarding process.

• Customer retention.

• The amount of users communicating with one another to purchase IP. Measured by number of messages initiating conversations between buyers and sellers.

Each KPI has analytics set up to track it. Iterations will be made based upon the findings.

Homeworks Energy

Objective 

We were charged with increasing the conversion rate of the sign up flow for home energy assessments. Homeworks Energy is a company that makes most of its money through inspecting homes and advising homeowners on how to make their homes more energy efficient. The monthly average was around 45% .

analytics

• Before the project began, there were no tools in place to measure the success of the online scheduler. No one was sure what the overall conversion rate was, much less the conversion rate of each individual page.

• My first step was to implement Google Analytics to measure the amount of users on each page of the sign-up flow. Analytics would give us a picture of the 10,000 foot view of what was happening in the checkout flow.

• It was clear that the contact info page was the page where we lost the most customers. The conversion of the contact info page was only around 60%, compared to the others that were 80-90%.

Session recording

I analyzed over 600 real session recordings of users attempting to sign up for a home energy assessment. The goal was to discover where the most users were giving up or encountering difficulties. 

• I found that most people were giving up on the contact info page before answering any questions. What I gathered from the session recording and the heuristic analysis was that users found the page overwhelming. They would simply look at the page and end the session.

• The second biggest problem on the contact info page was the address field. It appeared that the Chrome autofill feature was blocking our autocomplete feature and users were getting frustrated and giving up.

• Other notable issues noticed were poor error handling, Users were not being taken back up the page to incomplete or incorrectly filled out fields after clicking the “Next” button. The size of the buttons for heating type on the eligibility page were also causing issues for mobile users.  

heuristic analysis

I analyzed each element of the UI. I used both research from sources like Baymard and NNGroup as well as observations learned on the job. 

You can see all of my comments in the image below. Some of the big themes I noticed were the overly wordy phrasing of questions, not indicating which questions were mandatory vs. optional, gray text fields that appeared disabled and some colors used that were not accessible to colorblind users. 

Using the findings from our research I made a user journey map (seen below) where I outlined all the good and bad points of going through the flow. 

Some of the top issues were:

• Gray text fields that looked like they were inactive and made the page overwhelming.

• Copy that was not easily scannable. Text fields were labeled as “What is your first name?” instead of “First name”.

• Several questions turned out to be unnecessary after an internal review.

user research

I wanted to learn about who the users were exactly so we could make sure we were still catering to them. All the users were homeowners that tended to skew age 50+. A strong majority of them were using desktop, about 70% while ~28% used mobile and only ~2% used tablets. Knowing that older customers tend to be less tech-savvy, this made us focus on simplifying the flow even more.

internal research

Since our biggest goal was to simplify the UI as much as possible, we wanted to remove all unnecessary questions. This required talking to all the internal departments at Homeworks to ensure we were not losing any crucial information. After talking with members of the marketing, sales and operations departments we learned what we were able to remove, which was substantial, though not quite as much as I had assumed. Some questions which I had assumed would not be important turned out to be crucial for certain departments.

Design

When I got to the design the biggest focus was on simplicity and making the design more accessible to all users. Based on our internal interviews we eliminated as many questions as we could, simplified the phrasing of the questions, improved the error handling and made the pages less visually overwhelming.

I created the new designs in Figma with a prototype and full user flow (seen below) to ensure the developers would have a reference for how the product should behave. 

We conducted several usability tests of the new designs to make sure that we were not introducing any new usability issues into the flow. We were comfortable concluding that we were not introducing anything that would confuse users. 

results

As soon as we released our changes the overall conversion rate shot up from ~45% monthly to ~65% monthly, a 55% increase. The conversion rate of the contact info page increased from ~60% weekly to ~85% weekly. 

next steps

Once we solved these problems, other ones cropped up. There was a bug on the schedule page that occurred for some users that had not been apparent before and which customers were within service range needed to be corrected as we experienced some issues there.

There were some factors I was interested to see get A/B tested. For instance, changing the fields from gray to white was a source of controversy. I wanted to make sure we were making the right decision and used Google Optimize to A/B test the field color. Over the course of one month the white fields performed ~12% better than the gray fields. Once we had enough data we were confident we could switch over to white fields entirely.

The changes were an overwhelming success. Once the changes for Home Energy Assessments had been released we went to work on increasing the conversion rate for HVAC Sales. When we implemented similar changes using the same practices as before we increased the overall conversion rate from 24% to 55%, an 129% increase.

Gradebook Project

My first project at itslearning was improving the gradebook.  Gradebook usage was low in the US and the company was losing out on tenders because the gradebook was not working for teachers.

The first question we faced was, why don't teachers in the US like the gradebook? Just from looking at it we had some assumptions but we wanted to confirm those and figure out better solutions.

We talked to as many customers as we could. We conducted remote sessions and flew to districts over in Texas and Indiana to talk to teachers in person.   We conducted user interviews with teacher, students and admins to get a good perspective of the challenges that each group faces. We made sure they brought their computers with them so they could show us exactly what they were talking about. We were conscious that what users say does not always reflect their behavior so being able to show us how they use the platform was important.

Our main findings were that the gradebook did not allow teachers to edit their grades easily enough, they had a difficult time identifying which students were most in need of intervention and that it was a pain to transfer all of the grades into the student information system, the final destination for grades.

You can get a more detailed look at what we found in our research summary here.

Design Iteration

• The priorities were to make it easier for teachers to add or edit a grade and to remove the excessive and confusing number of options at the top of the screen. We checked usage tracking and checked feedback to figure out which controls were the least used. Most of the options within the “Action” dropdown were not well used, which may have been due to the vagueness of the label.

• It was important to allow teachers to quickly add and edit grades as well as exempt students, label work as late or forgive lateness. Initially, the design also included a way for teachers to leave a comment on work from the gradebook. Although teachers likely would have liked this feature based on our user interviews the team was never able to implement a comment feature. The visuals were also updated to better reflect itslearning’s new UI.

• One of the challenges was the amount of options needed at the top of the screen. Legacy features that were still in use by customers made this necessary as well as maintaining consistency with other pages in the platform. We knew teachers wanted to see as much information as possible in one view. I believed it important to allow teachers to scroll down to the bottom of the page and have the top row remain in view so teachers know which assessments they are viewing.

Usability testing

• I visited several schools to conduct user testing sessions with teachers.  Teachers found the main workflows like grading, exempting and assigning work as late to be intuitive. 

• The one area where we kept faltering in our tests was an area called batch grading.  One of our goals was to help teachers grade more quickly.  The batch grading feature allowed teachers to instantly grade a group of students which they could filter by course group or by assessment status (turned in late, overdue etc.).  

• The problem we discovered was that teachers were confused because they didn't really need such a robust feature.  What they really needed was a way to quickly jolt their students who hadn't done their work.  Teachers wanted to give their students zeroes more quickly!  Teachers were reporting that up to 40% of their students would not hand in their work on time so a big part of their job was reminding those students to hurry up and turn it in. 

• Learning this I made the decision that even though the UI for batch grading looked impressive it was too complex and unnecessary for what teachers actually needed to do.  Instead, we implemented the option "Ungraded = 0" into the menu for each assessment. This took care of the main use case and was relatively easy to implement.

UI Design

The new design for the gradebook includes easy editing for grades on the page, a less cluttered toolbar, a way to add comments directly from the gradebook, indicators on which assignments have been turned in/are late, and reporting on how each student has fared throughout the term.

Results

When the new gradebook was released we measured the success through two indicators.

• Is it still a roadblock in getting new customers?

• How often does it come up as a favorite feature?

Previously, the gradebook had been mentioned as a major roadblock in getting new customers. It consistently came up as a reason why teachers did not like the platform. After the release, it was no longer seen as a roadblock to potential customers and existing customers who had grade passback began listing it as one of their favorite features in itslearning on our annual satisfaction surveys.

prototypes

View the workflow for leaving a comment.

View the concept for the proposed, Standards Based Gradebook.

View the workflow for marking work as late.

User Research

In my time at itslearning I implemented a number of UX research methodologies, both quantitative and qualitative. These included user interviews, usability testing, happiness surveys, and NPS surveys.

user interviews

I have conducted a large number of interviews with users of itslearning.

usability testing

Various usability testing projects for the organization

Pedalboxd: Building a Guitar Pedal Discovery & Management App

View on Github

View project

Project Overview

Pedalboxd is a web app that helps guitarists and bassists discover, compare, and manage their pedal collections. It combines a clean, responsive React front end with a flexible data-ingestion pipeline that pulls specs, images, and pricing from multiple pedal manufacturers (Wampler, TC Electronic, Death By Audio, JHS, and more).

My Role

• UX Designer: Conducted competitor research, sketched wireframes & user flows, built interactive prototypes in Figma, and ran informal user tests.

• React Developer: Architected and implemented the production UI with React (plus CSS Modules for component-scoped styling), integrated Firestore for user collections, and built data-scraping scripts to automate pedal data imports.
  
  
  

Key Challenges

1. Data Consistency

• Pedal specs, images, and pricing come from disparate sources (CSV exports, Shopify JSON APIs, custom REST endpoints).

• Each brand uses different URL schemes, HTML structures, and field names.
  
  
  

2. Scalable Import Pipeline

• Need to add new brands over time without rewriting the scraper from scratch.

• Must dedupe existing entries to avoid cluttering the database.

  
  
  

3. Intuitive UX for Complex Lists

• Users should be able to filter by type (e.g. Overdrive, Delay, Modulation), price range, and brand.

• Provide a clear way to add/remove pedals from personal “boarding” collections.
  
  
  
  

UX Design Process

1. Discovery & Research

• Reviewed top guitar-gear sites (Reverb, Sweetwater) and competitor apps.

• Interviewed hobbyist guitarists to understand how they track and discover pedals.

  
  
  

2. User Flows & Wireframes

• Mapped primary flows: browsing pedals, viewing details, saving to collection.

• Sketched low-fi wireframes in Figma to explore layout, filtering controls, and card designs.
  
  
  

3. Interactive Prototype & Testing

• Built a clickable Figma prototype with core screens (Home, Pedal Details, My Board).

• Ran 5 informal usability sessions, iterated on navigation (moved filters into a sticky sidebar) and pedal-card hierarchy (image, name, price, core specs).
  
  
  
  

Technical Implementation

Data Pipeline

• CSV Imports (for legacy brands):

• Node.js scripts that parse vendor CSVs, normalize IDs, and upsert into Firestore—preventing duplicates by using consistent document IDs.
  
  
  

• Python Scrapers (for modern Shopify catalogs):

• TC Electronic: Hit their REST endpoint (/search/products-result), parsed JSON for modelCode, specs, and images.

• Death By Audio & JHS:

• Used Shopify’s public APIs (/products.json + /products/{handle}.json) to fetch full catalogs, extract body_html, price, and images.

• Stripped HTML to plain text with BeautifulSoup’s get_text() for clean “Specs” fields.

  
  
  

• Automation:

• Stored scripts under scripts/ with requirements.txt and a virtual environment.

• Added yarn scrape:tc and yarn scrape:db NPM scripts to rebuild data on-demand.

Front-End (React + CSS Modules)

• Styling:

• CSS Modules for encapsulated, component-level styles (no global leaks).

• Used BEM conventions for any shared utility classes.
  
  

• Component Library:

• Custom React components: PedalCard, FilterPanel, Modal, etc.

• Lucide-React icons for clear, scalable iconography.
  
  

• State Management:

• React Query for data fetching & caching; Context API for user auth/collections.
  
  

• Filtering & Search:

• Debounced free-text search across pedal names and specs.

• Multi-select filters for Type, Brand, and Price bands.
  
  

• Responsive Layout:

• CSS Grid for the pedal-card gallery with media-queries to stack on mobile.

• Modals for detail views on desktop, full-screen panels on mobile.
  
  

Outcome & Impact

• Data Coverage: Automated import of 500+ pedals across 4 brands, with nightly scripts to catch new releases.

• User Feedback: Beta testers praised the clean “Specs” formatting and fast filtering.

• Next Steps:

• Integrate user-submitted reviews & ratings.

• Add “board” sharing and social features.

• Explore a mobile app wrap with React Native.
  
  

Tech Stack

• Front End:

• React, CSS Modules, Lucide-React, React Query

  
  

• Back End / Data:

• Firebase Firestore, Node.js (CSV import), Python + BeautifulSoup (scrapers)
  
  

• Tools:

• Figma (wireframes & prototype), Git/GitHub, VS Code, Yarn/NPM scripts