Case Study: Abercrombie & Fitch E-commerce Front End
Four brands, thirty international sites, and one framework
Abercrombie & Fitch had four distinct brands running on four distinct code bases, leading to lots of duplicate development effort. My team engineered a front end framework so we'd spend less time chasing problems and more time building solutions.
When I first joined the e-commerce team at Abercrombie & Fitch, the front end code base needed a lot of work. Each of the company's 4 brands—Abercrombie & Fitch, abercrombie kids, Hollister Co., and Gilly Hicks—ran on its own set of JSPs, CSS files, and JavaScript libraries. There were different JavaScript libraries used across brands; some had jQuery, some had YUI, and some even had both being used simultaneously. Gilly Hicks, based on Flex, was entirely inconsistent with the other 3 brands. Any new feature requested by our business users required duplicated development effort. In many cases, up to 4 uniquely engineered solutions were required for the exact same feature.
Process was also a challenge. Ever-changing business requirements and new requests were pouring into the e-commerce department and flooding them with tasks for their weekly releases, but there was little process in place to handle the requests. Business users were accustomed to handing off thin requirements at the last minute and developers were working at a frantic pace with a QA process that consisted only of rushed peer reviews that were little more than a rubber stamp. Customer satisfaction and code quality were low, as was developers' morale.
Working alongside the e-commerce department's talented Java developers, my team replaced the FlexJS-based Gilly Hicks front end with an entirely new set of JSPs containing semantic, SEO-friendly markup, neatly organized CSS files with descriptive file names, and a new common JavaScript library standardized on jQuery. We decoupled the CSS and JavaScript from the markup, minimizing page size and cleaning up the JSPs considerably. Separating content from presentation also allowed us to create a site build that included only JavaScript and CSS libraries; we were able to deploy static changes without running a full site build, letting us respond faster to business requests. And well before "responsive design" had become the next hot industry buzzword, we'd constructed a front end framework that would require only CSS and JavaScript changes in order to accommodate devices of any size, e.g. smartphones, tablets, and netbooks.
Following an extremely aggressive development schedule and successful launch of the Gilly Hicks e-commerce site in July 2010, we saw significant increases in organic search engine traffic and much improved app server and front end performance. With the front end framework in place, we needed some breathing room to handle the deluge of maintenance requests while maintaining the new framework we'd built, so my next priority was to establish a firm process for handling weekly release tasks.
The biggest process challenge facing the e-commerce team was a failure to control and schedule incoming business requests. As long as the request came in by Wednesday, it was almost always expected to be in that week's Thursday morning release. I introduced a simple process involving cut-off times for various stages of the release schedule and established defined roles and expectations for everyone involved in the process. Put simply, all development, feedback, and iterations had to occur on Thursday, Friday, and Monday, and all business reviews and approvals had to be received by Tuesday, allowing us one full day for internal QA and performance testing prior to the Thursday morning release. Business users were required to be more engaged in the development process and take ownership of their requests, and developers became more aware of the quality control issues caused by rushed development and QA. The success of this simple process change helped alleviate mounting frustrations and QA problems and set us on the road to implementing further process improvements to come.
With both our code and our process on the road to recovery, we rolled out subsequent redesigns of the other 3 brands over the next 10 months on top of the new framework. Each brand redesign brought with it functional and design enhancements that had to be incorporated into all brands, and thanks to the streamlined framework, we were able to implement these improvements across all brands simultaneously with much less effort than separate code bases would have required. With the help of the ops team, we also introduced YUI Compressor and Closure Compiler into our build process to concatenate and minify our CSS and JavaScript libraries, further shrinking the size of our front end code and improving page performance.
During my second year at Abercrombie, we implemented a series of further improvements and enhancements to our front end code, including several iterations of our JavaScript framework and the introduction of practical cross-browser HTML5 that degrades gracefully, all while tackling massive projects like complete redesigns of our checkout flow and user account section. Bottom line: we got a lot done.
Today, Abercrombie's various brands are in a much better position to tackle future e-commerce challenges thanks to the work performed by the front end team under my leadership.