For the client, I probed their UX using multiple tools to determine low-hanging fruit, worked with the CTO and VP PROD to understand resourcing constraints given the product roadmap, and enumerate several tactics in a (prioritized) phased approach towards improving performance.
Heuristic discoveries included FE perf bottlenecks such as:
multiple inline JS snippets causing slowdowns
un-optimized JS libs, including of React components
multiple 3rd party JS libs that were no longer necessary
JS libs that loaded neither async nor defer
retrieval of multiple styling resources
I found that the greatest opportunity to optimize existed for two key user experiences at ~6s avg page load and ~4.5s average page load respectively.
During one iteration, changes lead to a 52% reduction in the Webpack bundle of React components, improving page speed by 10% or better across four key user experiences.
During another iteration, one key UX was sped up by 39.4% without Cache, 53.8% with Cache.
During a final iteration, changes lead to a 20% page speed improvement on one key user experience and 10% or better on two others.
Results
Introduced Performance Engineering mindset leading to 20% page-load speedup.
With no-one on staff having formal performance engineering experience or training, I led the effort to address a 6s sitewide page load average. Over approx. 6 months, stealing time from each sprint as I could given other responsbilities, I assessed bottlenecks using performance tools, including procuring a contract for Insights, Browser Pro, and Synthetics.
In a nutshell, assessing some of the pages having a roughly 13s page load, skewing the overall site’s average, I determined that the bulk of the performance issues were in blocking JS libs and then crafted a remediation strategy and established SMART goals for baselining/measuring impact of changes quarter-over-quarter with intent to drop from 6s to 3.5s by the end of 2017. Below you’ll see a spreadsheet I kept, noting the average Page Load Speed every Monday morning. Finally, in May, we address the bulk of the blocking JS libs and reversed the upwards trend.
The CEO was amazed at how much faster the site felt.
Results
Intro’d performance engineering, leading to page load speed reduction by one full second and 11% bump in mobile web conversions.
This was an enormous effort to overhaul a product whose UX had not been altered much in five years.
We took a piece-by-piece approach to swapping out components because of the complexity of the legacy behemoth. First, we refreshed the views in the legacy app, which involved changing styling in three different places (because the app had grown “organically” over the years, taking on three different styling paradigms styling was defined in custom stylesheets, in Less, and inline.)
In parallel, part of the team started building out the new peer Rails 3 app, the eventual destination for all views, complete with the company’s brand-new proprietary SSO solution (also built in parallel.) Finally, routing was updated to send all traffic to the Rails app.
Forming
Between August and September of 2013, we coalesced as a team under the project champion, the company’s CTO, and began formulating what the new UX should be and do.
Below is a screenshot of an example of the dashboard as seen by the end user (Merb, built in 2008)
Below is a screenshot of the progress of a microtask job, also as seen by the user (sensitive information redacted)
Norming
Between September and October of 2013, we cranked out the new experience.
Based on a design concept by the other F2E in the team, we began restyling low-risk interfaces of the system. The new design was not simply a reskin, but involved introducing a similar-yet-improved information architecture, an example of which can be seen below
Following are a few more example screenshots demonstrating the evolving look-and-feel
Configuration Panel
As we were tackling the UX, a backend engineer in a peer team was working in parallel to create a custom role-based SSO system that we would leverage for enforcing authentication and authorization in a new way for the company.
Shortly before the conference, a decision was made to go with a second design concept, not entirely different from the original, but a little more polished. A designer was requisitioned to provide the new design. From that point forward to product launch, we mostly fine-tuned the details.
The following screenshot demonstrates not only the new design but also the use of the new SSO solution, which can be seen where certain UI elements are disabled based on the user’s permissions
To QA the new experience, we ran it in alpha against production data repositories just prior to the conference.
Performing
After the launch, we maintained the product, adding features we had not been able to squeeze in.
Below is an example screenshot of how the final product shaped up
Results
Consolidated multiple styling paradigms for new UX ahead of company-sponsored conference.
The CrowdFlower platform is consumed via a number of microtasking sites. Each site registers and maintains its own users, but to better track unique identities across the CrowdFlower platform, we built a Single Page App in Ember.js to allow associating users across partner microtasking sites with one unique identifier in the CrowdFlower platform.
Results
Implemented a CRUD tool for managing users using Ember.js while iterating in conjunction with Product Manager as requirements changed.
Test Questions are used as the gold standard of quality in the CF platform, but they can be laborious to create, particularly for work that’s periodically repeated.
As no templatized solution existed, a team of three of us (me as F2E, Product Manager, and Backend Engineer) tackled creation of an internal product to simplify the workflow.
The user flow was to create “Cases” of Test Questions that got sent to jobs as “Batches”; where the composite idea of a “Mold” encompassed all “Cases” and “Batches” for a particular set of target jobs.
(“The Forge” was the product’s original name, derived from a time when “Test Questions” were known as “Gold.”)
One of the more challenging aspects of the project was the testing of the app. Selenium has always been a robust solution for testing even JS-heavy experiences, but given its heft, Poltergeist was used instead.
The product was to eventually be made available externally but never was.
