After focusing on other priorities, I was pulled into a revision of an interface (I had also created) as delievered for the Rich Data Summit allowing customers to send any model predictions under a certain threshold to the crowd.
I took the following (revised UX) static mock from Design
and iterated to deliver the following
Results
Crafted SPA as lynchpin connecting platform’s Machine Learning (Python) and human-in-the-loop (Ruby) systems after convincing team SPA was optimal approach.
I was getting close to integration and that would eventually prove the most challenging (given pre-existing styling interactions and positioning.)
I incorporated my work into the main codebase and iterated on styling and interaction from there. Also, I created a CoffeeScript spec for covering the main features.
Here’s the final product
Results
Re-purposed an existing drag/drop example using jQuery Draggable in order to facilitate data management.
Contributors, as they are called, are the +5M people around the world who do work on CrowdFlower’s platform. The application that enables them to do work is one of the company’s heavily trafficked as well as most complicated – blending a Rails backend with MooTools, jQuery, and RequireJS in the frontend.
The application’s UX
…had largely stayed the same for the last five years. In Q1/2014, we decided to enhance it by making it more interactive and towards engaging our users more and conveying the just how much work there is in our system.
Working with the Product Manager and an external Designer, we came up with the following high-resolution mock
Because the application is so heavily used, we knew we couldn’t merely throw the switch on a new design overnight; both from a community management standpoint as well as application performance. Instead, we chose a strategy of introducing a first at the company: use of A/B Testing to determine a design that would perform as well as if not better than the original.
Our key metric for performance in that regard had to do with contributor’s performance after being exposed to the new UX, particular the messaging around our forthcoming gamification and introduction of Levels. In the beginning, we did not have the infrastructure to determine the value for that metric so we simply settled on ‘clicks’ as a (conversion) proxy to understand if the new design was having an impact.
Infrastructure
Without an A/B Testing framework in place, I needed to choose one. As requirements were not concrete for such, I did some due diligence in vetting several options, coming up with a review of A/B testing frameworks for Rails.
It became obvious that Vanity was best suited to our needs. (Since it doesn’t yet have the ability to throttle a percentage of the traffic receiving experiments, I augmented it with Flipper.)
Once that was in place, we could begin iterating on the design, knowing with confidence how we were impacting the user experience.
Server-side
We knew we wanted the experience to be snappy, but completely replacing the existing experience with a Rich Internet Application was far out of the scope for the first month, particularly as there were infrastructure changes to be made to retrofit the stack with A/B Testing. We decided to make progress iteratively over several sprints.
In our first test, we pitted the control (original) against a bare-bones implementation version of the high-resolution mock as the new design.
original
The new version out-performed control (in terms of clicks) 21.3% vs 20.3% (at 95% confidence) so I continued to iterate on the implementation, coming up with the following
To calculate the overall satisfaction by other contributors for a task (denoted by the stars) proved to be too inefficient in this iteration; it wound up losing.
Client-side
On the assumption that we needed to make the experience snappier in order to drive engagement, it was obvious that we would need to have more (and faster) interaction and therefore, an interactive client-side implementation.
As what was essentially a completely parallel product, leveraging only some of the infrastructure that the server-side rendition was utiziling, I begin to flesh out the following
Further refinement (an actual data) was necessary to get it looking more like the high-res mock (and like its server-side-rendered peer)
At this point, we implemented and integrated with our own homemade badging solution, beginning to display badges in the following iteration
The new version out-performed control (in terms of clicks) 21.3% vs 20.3% (at 95% confidence) so I continued to iterate on the implementation, coming up with the following
Testing the impact of particular messaging was also of interest, so we added a Guiders variation as well. At this time we also leveraged Google Analytics Events on the Guider buttons to track how the far the user got in our messaging.
Letting the experiments run a few days with sufficent traffic, we found that client-side-rendered version peformed no worse than the server-side-rendered version (23.9% vs 22.9%) and that having guiders also performed not significantly worse (23.1% vs 23.7%) so we decided to keep both.
By that time, the new version was out-performing control (the original design) 22.2% vs 20.7% (at 99% confidence) so a decision was made to move forward rolling out the new experience to 100% of contributors, doing some polishing (copy/styling) work before finally settling on the following
Results
Used A/B testing to upgrade company’s most highly-trafficked page (5+M views/month,) increasing user engagement by 5% and saving $2K/month (in Bunchball costs) by rolling own simple badging solution.
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 app is CrowdFlower’s most highly-trafficked app. It also happens to be one of the company’s most technically complex, given its history.
Its architecture is that of a Rails app, wrapping a Gem that extracted business logic from the company’s legacy (original) Merb app. The Gem contains all logic around rendering, styling, and providing interactivity for CML, the basis of abstracting microtasks in the platform.
The app was built (before my time) in order to bring a richer, more interactive experience to those doing microtasking work. When the original architect departed only weeks after I joined the company, maintenance and feature implementation fell to me.
Results
Supported site’s most highly-trafficked, revenue-generating UI (allowing for custom JS and CSS.)
Shop It To Me has been a beloved service for years when it comes to finding the best deals across retailers, but we wanted to enable the user finer-grained abilities to find exactly the item(s) of interest for them.
We often had feedback about being able to drilldown by clothing type and brand (e.g. “Rebecca Minkoff handbags”) but our previous tools didn’t enable that kind of granularity.
Enter “Threads.”
As the brainchild of our CEO, project “Threads” has become a way for users to track the specific items of interest to them. We now empower the user with the ability to get as general (e.g. “Black dresses”) or as specific as they want. (e.g. “Rebecca Minkoff handbags under $300.”)
Below, you’ll see the hi-res) mockup we came up with (after having previously white-boarded the idea) in early March (click to view.)
inspiration (as mocked-up in Photoshop)
Over the following two weeks, I ramped up on Ember.js and implemented the first version of the app while the other engineer built out the pseudo-RESTful backend. I won’t claim that the code we produced was the cleanest either one of us ever wrote; while doing the best we could, getting to market was the true driving motivator.
We went live – that is, deployed to production for internal and a select group of test users – on March 27th, 2012, with the following (click to view)
very first landing page
Based on user tester feedback, we decided to bolt-on onboarding and improve the look, so four days later on March 31st, 2012, we deployed the following (click to view)
revised landing page with header and pseudo-onboarding
Based on observations during user testing, we realized the opportunity to incorporate a feed of site-wide activity as that would benefit discovery. We also took a few cycles to flesh out onboarding and a “Things To Do” list given challenges users’ had in making sense of the new product. We also tweaked styling to highlight the very newest items in the users’ results; screenshots follow (click to view.)
onboarding modal on landing page (4/11/2012)
1st try: TTD/activity feed on landing page (4/11/2012)
2nd try: TTD/activity feed on landing page (4/12/2012)
emphasizing new items (released 4/12/2012)
We brought in more and more user testers. Here’s a screenshot from April 17th, 2012, showing progress we made from our observations
4/17/2012 release of results page
While observing user testers, we discovered that they wanted tastemakers to help them navigate the overwhelming number of apparel items, so we introduced the concept of curation. We also made the assets/images larger by popular demand.
curation (4/23/2012)
results page (4/23/2012)
results page w/larger assets/images (next day : 4/24/2012)
After April 24th, we stepped back to assess how we were doing. I was rotated onto our bread-and-butter projects but the team was augmented with other talent and continued forward, contracting the look-and-feel out to a third party.
The product has since been retired.
Results
To revolutionize personalized shopping, a team of three (the CEO as product manager, me as the F2E/architect, another as backend engineer,) created a new shopping experience using Ember.js over two sprints
Ramped up quickly on Ember.js
Architected frontend as a Single Page Application
Worked with backend engineer to agree upon/implement integration between FE and BE
Drove development through four major iterations during a two one-month sprints
Suggested (though not responsible for implementing) lazy-load as a way to improve performance
Picked up design slack when we lost our Graphic Designer
Scoped frontend deliverables and managed expectations
Worked with CTO to coordinate out-of-cycle releases to production
Since retired, the product was the first foray into the world of premium subscriptions. We went through 35 variations of the invite email while experimenting, five of the landing page, and several promotional creatives embedded within the flagship email product.
Here’s one example invite (click to view larger):
The product has been retired.
Results
implemented company’s first subscription product
Created a Chrome browser extension (using jQuery based on ease-of-namespacing) as a complementary value-added delivery channel
Delivered HTML promo emails, details/purchase/confirmation pages (models, views, and controllers,) CRUD admin tool, and gateway payment processing via ActiveMerchant and Braintree (including mid-tier error-handling logic)
