Introduction
Essay Eye
Essay Eye is an Edtech startup that utilizes AI to assist the essay grading process for teachers.
I was contracted in August 2024 to help design and develop the initial website ahead of the product launch. The goal of this website was to showcase the product, the company, and to get conversions. My work with this website includes product design, frontend development, graphic design, and branding.
Team
Tools
Figma, ReactJS, Typescript, CSS, Git, Github, GhatGPT, Notion
Timeline
2 months
Aug - Oct 2024
Feature Overview
Right off the get go we were in active contact with our primary stakeholders Scott Isley (Essay Eye’s CEO) and David Bridges (Essay Eye’s CTO), and one of our first discussions was drafting a feature overview. This was a mix of
Stakeholder input
Our contract listed out these as our deliverables:
-
Homepage
-
About
-
Features
-
Pricing
-
Safety
-
Contact
-
Instructions
What's Typical?
We sourced this information based on what we knew about website structures, common sites we used, online inspiration resources like Dribbble, and just what we commonly saw on the Internet. These are some of the site elements we felt necessary to add:
-
Nav bar
-
Logo
-
Features
-
Pricing
-
Safety
-
About
-
-
Testimonials
-
A welcome banner
-
Call to action
-
Product demo video
-
Stats/benefits
-
Main features
-
Faq
-
Footer
From there we looked at our competitors in the industry and tried to pick out some elements that might work well for us particular to this niche.
Competitor Analysis
To guide our design strategy, we analyzed four products (SchoolAI, Magic School, Humy AI, and Brisk Teaching) to further understand standard design elements and UX patterns. By examining common features and identifying elements we wanted to incorporate or avoid, we established a foundational vision for our site that aligns with industry expectations while offering unique improvements. Based on this, we started designing.
Designing
Common Footing
We started off trying to set a common footing. I led the creation of a cohesive design system—defining fonts, colors, icons, and components—to prioritize both accessibility and brand identity.
Likewise I took the lead creating a common footing for our workflow. I did this by setting up a Notion board as our project roadmap and managing tickets to keep our work organized and clear of misunderstandings. Below is that roadmap
The Best of Both Worlds
I suggested starting off by designing separate frames. We’d work on the same file, but since we didn’t know much about each other’s design styles I thought we could get more ideas out by designing separately and then coming together to combine for the best of both worlds. These were our initial explorations for the website
Narrowing Focus
We then met with our stakeholders, went over what we liked/didn’t like, and then merged our efforts onto a common frame. The goal now was to create a set of frames that 1) delivered on the primary goals of the website 2) fit the stakeholder desires 3) was modern and aesthetically pleasing 4) was realistic to develop. Here’s some of our major iterations
Next we took on designing the logo of the company
Logo Design
Designing Essay Eye’s logo was a task that we had been iterating through from the start of our contract basically until the end of it. We went through a lot of variants by exploring different
Now we were ready to jump into a final prototype
Prototype
The goal with the prototype was to make something that would transition well to development. We continued making design changes as we developed, but as far as large design efforts went we were moving on to making it a reality
Development
ReactJS
Without a solidified tech stack, the development of our designs was free reign. I chose to utilize ReactJS for a few reasons:
-
I had prior experience with React
-
Modularity and component based programming
-
Easy to learn/use
-
Modern, widely used, lots of resources
Collaboration: Git & Github
As development was underway, we had to think about how to collaborate. Emailing files between each other wasn’t going to last long, so I turned to Git and Github. I had interacted with Git and Github before, but this was my first time using it to actually collaborate with someone else on a codebase. After some rough waters we successfully began collaborating on one repository, drewren25/essay-eye. We were given access to the company’s codebase when we took on the role, but they didn’t have much on there for the website and I didn’t want to make any changes yet that wouldn’t be compatible with React. Unfortunately for me, problems would be inevitable.
It...Doesn't Work
Initially trying to push our changes to the Essay Eye codebase was a disaster, but I learned a lot. Our workflow was all wrong and we needed to account for our CTO’s use of Express in the backend which couldn’t be used with Vite, the default for React apps. There were a lot of late nights, YouTube tutorials, and ChatGPT prompts but at the end of the day we were able to finally work things out. Here are a few key points/learnings we ended up utilizing
Separate branches and PR’s
-
Because I was only used to pushing code to solo projects, my previous workflow was just me working on the main branch and pushing directly to main. Obviously this doesn’t work when working with others. That’s when I learned about the importance of different branches and push requests, things that help the process of collaboration without stepping on other coder toes.
Keeping up to date
-
Also because of my previous solo experience, there was never a need to keep up to date with the code because I was the sole contributor. This is not the case when working with other people, and an emphasis had to be made on keeping code up to date when working.
It...Works!
And finally we developed a good enough workflow to get things up and running! Feel free to do a more in depth exploration of the site here
Takeaways
Product is about balance
In my professional experience, there has been a great and deserving emphasis placed on the users of a product. I mean, it’s in the name, user experience. However this experience gave me real world perspectives onto an insight I only scratched the surface of before, the fact that it’s more about balance. The user is important, but the stakeholders, business goals, and the design to development transition are all arguably just as important when crafting a product.
Communication is key
This experience was a first in many aspects. It was my first time working with others on a live codebase, my first time bringing this complex of a design to life, my first time holding a design meeting until midnight. In all aspects though I relearned the important lesson that communication is key, and by communication I mean clear communication. Especially in an early stage startup, things can be messy and responsibilities can be foggy, so communicating between our CEO, CTO, and my partner design engineer was key to getting work done, setting expectations, making requests, and getting the project done.
You can’t know everything
If the previous lesson wasn't the most important, this one is. Doing this project solo was beneficial, but it also made me realize how important collaboration is. I could have saved a lot of trial and error and potentially come up with an even better solution had I other people to bounce ideas off of.
