Rebranding XYMOGEN.com
Wed Jan 15 2025, last updated Thu Jan 15 2026
XYMOGEN.com is a large scale, high volume, direct-to-consumer vitamin and supplement e-commerce platform. In February 2023, the site underwent a reskin, during which I was named the Product Owner for all front end features. Later, in January 2025, the company rebranded and the website was once again restyled, with me assuming a leadership role regarding all front end activities.
During the initial reskin, I identified a number of opportunities for process improvement, codebase refinement, and other means for efficiency within the developer workflow. One of the more impactful ones being the introduction of scss to our tech stack.
Introducing SCSS
Adding scss to our toolset allowed us to better integrate with the newly developed company design system, initially from Adobe XD, then eventually from Figma, created by web designers from the Marketing team. The design system provided us developers with rules, variables, and layout specifications for all components and pages.
By making these available to us, I was easily able to compile all the most granular items and variables, and reformat them in scss, creating a pixel-perfect link between the prototyped design system, and the rendered code in the browser.
From that point on, the design system became the source of truth for all style related questions. This drastically improved development time, collaboration across teams, and brand consistency online.
Design system implementation
At it’s core, implementing the design system meant creating project level variables for all the smallest building blocks our designers use to create and update web components. Mainly things like colors, spacing increments, typography rules, etc. These all needed variables to be accessed and replicated on the fly.
I also wanted to make sure all these new pieces were easy to find and update. Learning from the legacy codebase, which included a behemoth mess of a custom Bootstrap stylesheet, tens-of-thousands of lines long, littered with !important flags and duplicated or conflicting selectors, I implemented guidelines for the structure of all our newfound scss files and folders.
sass/
|
|- abstracts/
| |- __abstracts-dir.scss
| |- _animations.scss
| |- _fonts.scss
| |- _variables.scss
|
|- base/
| |- __base-dir.scss
| |- _reset.scss
| ...
|
|- components/
| |- __components-dir.scss
| |- _card.scss
| ...
|
|- layout/
| |- __layout-dir.scss
| |- _footer.scss
| ...
|
|- pages/
| |- __pages-dir.scss
| |- _account-page.scss
| ...
|
|- styles.scssThe _*-dir.scss files @import (or now, as of Dart Sass v1.80.0, @forward) all other scss files within the same directory. All _*-dir.scss files are then compiled in the main styles.scss file, which gets compiled and included in the site’s layout.
This predefined structure is paramount to avoiding merge conflicts and keeping the codebase organized. By no means did I invent this structure. Simply Google “scss folder structure” and you’ll find plenty of near identical versions of this same concept. But introducing it into our project, knowing the horrors that came before it, felt pretty groundbreaking.
scss’s support for multiline comments also proved useful for this project, as it allows developers on my team to share component code snippets and patterns directly in a component’s scss file.
BEM naming conventions
To avoid the pesky selector conflicts and overrides I mentioned earlier, I proposed we adopt some form of naming convention for our styles. We decided to implement BEM (Block Element Modifier) rules with great success. This was imperative for our codebase as we aren’t using style modules or other methods of compartmentalizing our style rules, so adopting a naming convention system was the easiest way to avoid conflicts.
Looking ahead
While it may not be anything too extraordinary, I am proud of what I was able to accomplish for our humble, six-person Web team at XYMOGEN.
In the future, I envision a more dynamic, automated link between what’s in Figma and what’s in our source code. Perhaps by regularly exporting tokens and variables from Figma and adding a build tool that automatically formats the output into our project. I’ve discussed this with the design team already, but as it stands currently, the number of variables and tokens they need for designing far outnumber the number of variables and rules we need for developing said designs.
For now, what we have just works. And if it ain’t broke, don’t fix it. But also, maybe try to break it sometimes, so you can figure out how to fix it better.