How a one week project ballooned into two months, and how a copycat design transformed into something original

Early January, a friend approached me with what seemed like a simple website design job for their video production company named Brickhead. They currently had a SquareSpace site that looked very template-y to say the least.

The idea was to just rig together a site that basically looked the same as this one.

“Ok, simple enough” I thought to myself. This should ideally take around one week to complete, maybe two just to be safe. Pomp & Clout, the site we wanted to emulate, seemed to follow a simple CSS grid with two columns on just about every page. Within those columns, the same card component was repeated across the entire site as well.

2-Column grid across the site.

The next step was to start building out components. I decided to start with the grid and cards that made up the works that this company had produced. This is how I broke it down:

Three components were used to populate each card, and the fourth was a Flexbox to accommodate however many projects there would be.

Once that was mapped out, I went ahead and mocked up a page to get a better sense of how the whole site would pan out. In addition to the grid of cards, I also added a dummy header to the top as well. Things were looking pretty good for the first day!

Mobile First

(Not a fan of YT Shorts, and even less so now as it seems like Medium doesn’t support the format)

The rest of that week went pretty smooth, and by the end, the design was pretty much exactly like the inspiration site’s. The screenshots below were for the ‘About’ and ‘Collaborators’ pages; the ‘Works’ page would contain the cards I worked on above.

Pretty uninspiring

I had some qualms about the design, but I assumed it was fine, as the full design scope wasn’t really discussed from the start — more on that later — and it really did seem like just getting something online that didn’t look like a template was the goal.

Part of it was my fault, and the other part just lay in how ideas were communicated. Historically, I’ve been more concerned with making sites functional first and worrying about design after (at which point I run out of energy to worry about). So in my mind, this seemed to have been “complete” although it did seem very text heavy and simple in terms of what the site had to offer.

Communication-wise, I think there wasn’t enough of an emphasis from the start that it needed to fit a certain look, and hold up under scrutiny from an industry that relies heavily on surface level inspection.

Fast forward a week, and the decision’s made to give the design an overhaul. Luckily, both my friend and I knew a UI/UX designer who helped us out. Her portfolio is here.

This design was light years ahead of the first iteration. Text wasn’t cluttered, there was usage of negative space, and the blueish-red color theme for Brickhead was integrated into the design. The creative principles for this new design were concepts I’d learned before in class, but never really had a chance to apply and hone. This was a pretty cool ‘a-ha’ moment for me when I first saw the Figma file.

The race was on again to overhaul the UI, and try to get the project done ASAP. From the business side, the sooner they had a new website the better, and for me, the sooner I finished this, the sooner I could get my other tasks done. I remember this being a very stressful 4–5 days as I juggled this along with midterms, and internship hunting.

During the overhaul, I ran into relatively little obstacles, although one stood out in particular.

Project card components with their populated info

Getting the text to stay both inside the card (some titles got reaaaaaaally long), and have it scale in the same position as the web browser changed sizes was tricky.

This was another learning moment for me personally. I developed the UI inside a fixed size browser (as big as it goes without fullscreen), so I ended up doing some hacky code to get the text to stay in the same place across all cards. Lo and behold, when had the site tested, users with a different browser size, saw the text get all messed up.

The problem was I was setting the text container’s size to either Vw or Vh percentages, so scaling worked fine as long as the window was dragged diagonally. If it was changed either just length-wise, or height-wise, the text would break out of their container and shift from the correct position.

The broken text turned out to be a larger issue than I thought, so I had to dig back into the CSS and try to redo the original styling. At this point, it was a couple weeks after I’d first implemented it, and the logic was getting a bit fuzzy.

Eventually, I did manage to fix it a decent amount, but it’s still not perfect. It was a combination of smaller font size, adjusted container sizes, and developing around ‘Vw’ (view width) for sizing, as it seemed like people were more prone to changing the width of the browser than the height.

I had one or two more updates to the side brought up right before the final deadline, but luckily I’d managed to set up my components correctly (whew!) to accommodate those updates.

Lightrange, a VFX company acquired by Brickhead.

One of them was the VFX page. Initially, there the menu tab for VFX was to redirect to Lightrange’s own website. However, it was decided that it was un-professional to have to do that, and it’d be more cohesive to move the media over. This sounded like a lot of work at first, but I was able to use the same components for the projects page, and was done in quite literally 40 minutes.

Both the client team and I were pressed for time throughout the whole project, and this was only made worse by a moving deadline. At times it felt like a lot of the inaction from the client side was at odds with the goal of getting the website done ASAP.

I should mention that halfway through, my friend had to delegate to his co-producer for a period of time to tend to other Brickhead needs. This created some friction in the design process as not everyone was on the same page anymore. There were times when I’d finished my part before a deadline to bank in extra time for edits, but then would receive feedback on the day of the deadline. This was frustrating, and luckily there was improvement after I’d brought it up to the clients.

There were some other *small* issues that were present early on, and then snowballed into delaying the project later on. Namely, missing media for projects, misspelled words in documents, lack of a title format, and different thumbnail size ratios (this was a big one). As a developer, it felt unfair to have to catch the mistakes of the clients whenever I was halfway through adding a new feature. I didn’t have a perfect solution, but once this started becoming a trend, I explicitly told the clients exactly what I needed to have ready from their end before I began.

For example, before I started work on a VFX page, I needed: “A folder named ‘VFX’ in the drive (don’t make me have to dig for it), each project with its director, title, and thumbnail included, and the embed links to the Vimeo/YT video”(grabbing the embed link with the proper settings takes time on my end if I get just the normal video url). These seem like details I could easily fill in, which i did have to at times, but when there’s 40+ project folders to deal with, that’s a lot of wasted time spent finding and formatting stuff + compressing images, and not building the site.

To be fair, it got a lot better within the last week or two. Both sides were open to suggestions on how to improve as the project went on, and those improvements were applied. The clients managed to have all the files ready, and used a checklist of tasks broken into smaller chunks for me to complete. At the start, we spoke in broad terms which meant different things in each person’s minds, so details that only one team knew of, were lost in translation.

I started work on this in Mid-January, and finished on April 1st. There ended up being a good amount of time lost just waiting for certain bits and pieces, like a finished highlight reel, because they were the last things to be added.

There were moments where I really hated client work, and swore never to do it again. But I do feel it was a very valuable experience. I got to see a lot of rookie team mistakes, and got to practice communicating what needed to be done in order to move the whole project along. It felt good to have had a cohesive team experience towards the end.

And finally, I’m glad that the finished result looks so much better than the first iteration!!

Check it out below, or here at



A blog for documenting my thought processes over the course of a project and how I can improve upon them in the future. Writing challenges me to build a “tree trunk’s foundation” [Tim Urban] of knowledge as I tackle new challenges.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store