This engagement was with a Fortune 500 business-to-business hardware company. The client selected SAP Hybris to re-platform two disparate e-commerce sites. One was a publicly available site for small and medium-sized businesses and the other a closed site for enterprise customers. Though each had different user needs, workflows, and features, the client wanted a consistent experience in-line with their nascent branding standards.
My role was to develop a style guide / UI library to support the broader development effort (a large team based offshore). I worked closely with a product designer that created workflows and visual designs for the new sites. The two of us worked closely with client product owners to gather requirements, define the overall user experience, and validate interface ideas. We also collaborated with the internal UX team to contribute UI patterns to their broader redesign project.
I created responsive versions of layouts (using desktop mockups as reference) and did rapid prototyping of interactions/layouts for technical feasibility and browser support. There were cases where the product owner's initial concept was not executable in the tech stack or supported browsers, so I had to pitch compromise designs. I built demos of pages with realistic mock data (e.g., real product names, codes, prices, etc.) to test content-related edge cases.
Atoms / Buttons
To guide the development process, I crafted a UI library with hundreds of components ranging from simple atoms (e.g., buttons and form inputs) to organisms (e.g., product carousels and table elements) to layouts (e.g., product configuration page sections). I wrote the CSS and jQuery for UI interactions used in the final product. I documented the markup in the style guide and mock HTML pages. Eventually, I built a mock HTML page for most major and many variants of pages, totally 150+.
I wrote the UI library in highly customized version of Fabricator. I originally chose Fabricator because of its flexibility and extensibility. However, I didn't realize at the outset just how much customization and refactoring would be required to meet the project's needs.
Initially, I rewrote the specimen templates to have more robust information about colors (included alternate color formats and accessibility information) and typography (included custom HTML elements and class names). I added a specimen for breakpoints. This required mostly Handlebars templating work, but also adding a Gulp task for the color-related computations.
I liked the idea of defining styles in JSON for style specimens, but I wanted a single source of truth rather than duplicating values between JSON and SCSS. I added a Gulp task to share color and typographic values to Sass variables.
Fabricator only had a basic image pipeline with no icon management system. I added an icon build process that converted a directory of SVG files into a SVG def file that was inserted into the HTML files (for better browser support than an external file). I rounded out the asset pipeline beyond images to include favicons and custom fonts.
To link design and the UI library, I expanded the page template to accept a link to mockup (hosted on Zeplin) in front matter, which would display as a link on the page list.
Finally, I collaborated with a front-end colleague to make Fabricator more robust for the size of such a library by building individual pages for material directories as opposed to rendering the entire library on a single page. For example,
src/materials/atoms/buttons would distinct pages. I created a new breadcrumb navigation to give transparency into the organization of materials. We also made the JSON data and Handlebars template handling more fault tolerant and hot reloading more reliable. By the end of the project, there were far fewer cases that required restarting the dev server. Debugging was still challenging because error logs didn't provide enough information, this would be resolved on my second project with this customized instance.
After all that work to enhance and refine Fabricator, there were still some serious workflow issues that we couldn't quite resolve. This was the impetus to develop of Tenderwolf, a more data-driven successor to Fabricator.