Customers: Multiple with many unique attributes (Retail or Wholesale, Global or Region-specific, varying product/service set and needs)

Role: Researcher, Designer, Developer, Tester, Content Coordinator, Systems Architect

Challenge: When I joined the team there were a large number (1,500+) of customer portal sites, which needed a lot of improvement. Among the problems…

  • Basic and outdated – The sites were mostly text and HTML, with poor implementation of CSS. The layout was table-based and the code was littered with improperly nested <font> tags and other outdated methods.
  • Lacked functionality – There wasn’t much a user could “do” on the sites. Interactivity was very low as there was little to no scripting.
  • No metrics/analytics – We had no idea who was using the sites, how they were being used, or any insights as to the user’s behavior or environment.
  • Manually creation process – There was no official codebase. To create a new site, the process was to copy/paste the files and folders from an existing site, find-and-replace the previous customer’s name and painstakingly look through the code on each page to find whatever information might need to be changed.
  • No version control – The remote server contained folder after folder of date-versioned copies of folders, with date-versioned files inside (e.g. ./customerName/2021_final/index_20211231.html). If a mistake was made and uploaded or something was inadvertently deleted from the remote server, the best course of action was to cross your fingers and hope that a teammate had a semi-recent copy of the same files on their local machine.
  • Production-only environment – There was no UAT/QA/Staging environment. When combined with the bullet above, this was an especially dangerous situation.
  • Not data-driven – There were no APIs. No connections to databases. There were no “common” or shared files.
  • No consideration for accessibility – The sites lacked alt tags on image, were presented in English-only, weren’t using semantically-correct HTML, and made no use of aria attributes.

Project Summary: Over time, these sites were vastly improved resulting in a better experience for the customers, became more manageable for the business, and were modernized for those who maintained/supported them. Addressing the bullet points above…

  • Updated to modern layout using Bootstrap framework, incorporating Flex (CSS), and proper separation of HTML structure versus CSS styling. Eventually many sites were using a build process where SCSS was compiled. This allowed for quick styling updates via variables and performance improvements through file minification.
  • Sites became very functional, eliminating the need to users to seek out a multitude of different resources for tasks they expected to be handled in one place. User creation, custom event set-up, and customized help were made available through interactive features that took the place of Word document forms that required downloading, customer completion, and order review with the customer and a company representative. Interactive self-help features were added to help users troubleshoot issues in real-time.
  • Using Google Analytics, I was able to improve security and stability of our services by removing customer sites that were no longer needed. However, the benefits didn’t stop there though as we now had insight as to what languages our visitors were looking for content in, what browsers/devices our customers were using and we needed to support or focus efforts on, what the most popular content was and users might be experiencing issues. We were also able to share this information with others within the company to help them gauge how effective their customer efforts were and to demonstrate value for the services we were providing.
  • Through common content stores, we were able to ensure that our product information was up-to-date, easily editable, and consistent across multiple sites. For example, if a partner/provider’s name changed we could easily make updates in one place versus thousands and have those changes immediately reflected across multiple sites. I developed a means for internal users to request site builds, which collected the base files from one repository that we kept up to date and dynamically created a configuration file that controlled the products/services available on the site, allowed for regional and business unit variations, and more. After a site was built through this process, it was able to be deployed onto QA servers (which were now readily used and matched our production environment), ready for any custom content or functionality, and otherwise available for review by the requestor and their customer.
  • All sites and files were added to version-control via Git and our enterprise GitHub account. This allowed for easier branching when new features were requested or developed and deployment onto QA or Production servers. It also allowed us to keep track of when, why, and what changes were made to sites and got us using best-practices to be able to easily rollback changes. From a systems perspective, this also allowed us to clean up a lot of “old junk” from the remote servers for files and folders that had been kept around “just-in-case”.
  • By connecting the sites to APIs within the company, we were able to automate the user-creation process from a once manual activity. This allowed the user to request a profile and begin using it within 20 minutes whereas previously, that might have taken 24-48 hours. I was also able to leverage APIs to provide hosts and participants with up-to-date dial-in numbers for their audio conferences, check for existing user profiles (and resend information if desired), and improve the user experience for location-based choices. Token databases and process were used to control access to services, as well as reCaptcha (v2 and v3) were implemented reducing fraud and spam. Common content was leveraged across sites for a consistent and easy-to-maintain experience. We also were able to leverage product APIs to allow users to start and join meetings from their portal sites making them a more “one-stop-solution”.
  • Accessibility was improved by allowing for multi-lingual support. This was originally implemented as a browser-based detection, then string file inclusion, then later changed to Google Translate API (We found that after initial translations, the edits would only come to us in English without any budget or thought given to translating to additional languages. As a result, it was deemed better to have all of the content translated even with the caveat of knowing that the translation might not always be 100% accurate versus having content missing or unexpectedly switching between languages.). Semantic HTML was used to give the site structure clear meaning to browsers and screen readers, and more consideration was given to accessibility features like alt attributes and color contrast.