ShareThis was founded in 2007, and offered one of the first embeddable share button widgets for web publishers. The tool was a valuable addition to a publishers site, allowing their readers to quickly share a piece of content to a growing number of social networks.

ShareThis offers it’s tools and services to web publishers for free. In exchange, ShareThis collects interest and intent data through the javascript that powers the tools, and re-sells the data to brands, publishers and agencies in the form of audience segments, and raw data.

This project was completed over a six week period in early 2017. I worked in close collaboration with a product manager, and two engineers.

 Getting the lay of the land

When I got to ShareThis I quickly began scheduling 1 on 1s with internal stakeholders across the company to gain a better understanding of the share button product and it’s history.

I found a product that had for all intents and proposes been abandoned. Many internal stakeholders viewed share buttons as a commodity, and thought they represented little in the way of enterprise value. Development of the share buttons had been deprioritized, and shipped off shore in favor of new (though yet-to-be proven) products. The results were apparent: Decrepit code and a broken, dated experience.

Internal data clearly showed the number of sites using the buttons were in sharp decline. Less than 10% of new publishers completed the configuration and registration process. Of those that managed to install the code on their site, over 50% removed it after 24 hours.

Share button on-boarding and configuration prior to redesign

 A case for share buttons

There was a bright spot in the otherwise gloomy share button outlook: People still wanted them. Thousands of people a week would visit ShareThis.com and start the configuration process. The proliferation of other similar services was further indication of continued interest in the product category. The reasons a publisher might abandon ShareThis share buttons appeared fairly obvious and relatively easy to address.

A hypothesis was formed: Revamping the share buttons would result in an increased number of publishers completing the configuration process, and decrease the number of publishers churning once the code was installed. For the business, more publishers meant more data, and more revenue.

Research

Publisher demographics

Prior to beginning design work, I wanted to understand the makeup of the existing network of sites currently using the share buttons. ShareThis has a robust ability to measure what’s happening on their network, so without much trouble I was able to query their SQL database and output a breakdown of domains grouped by pageviews per day. The vast majority (over 75%) were small sites receiving less than 100 pageviews a day.

Distribution of websites using share buttons by daily pageviews

Usage of the legacy share buttons

In addition to the make up of the network, I also researched usage of the six different types of buttons a publisher could select when configuring buttons for their site.

Over 50% elected for basic, square buttons with rounded corners that were placed inline on their pages. Internally they were known as “Chiclets”. The next most popular button type had a call to action a share count for each social network, also placed inline on a publishers page. “Chiclet – Side Bar” was the next most popular option. It was a vertical arrangement of chiclets that stuck to the side of a visitor’s browser window.

Popularity of legacy share button types

 Publisher surveys

In the process of conducting 1 on 1 discussions with internal stakeholders, I discovered buried treasure: a very thorough satisfaction survey had been conducted via email one year earlier. Publishers provided their overall satisfaction with the service, along with suggestions for improving the product.

The feedback had been organized into categories and clearly indicated patterns of discontent which aligned with our assumptions. Negative responses regarding performance, the look, feel and ability to customize the buttons, as well as missing or inaccurate analytics and reporting topped the chart.

Love letters!

 Competitive analysis

After sifting through the publisher feedback, I took inventory of top competitive products. Many of their features were repeat requests in our publisher feedback – though not all of them were free of charge. It was also interesting to note the variety of customization each service provided as well.

 Proto personas

The research in conjunction with the team’s own intuition aided in the creation of loose, proto personas. The personas ensured the team was in alignment and provided a foundation for product and design thinking. The primary focus in the initial re-design of the buttons was “The little guy” and the “Move Maker”.

Three broad groups of publishers

Validating assumptions

 Experimentation

With research and personas in hand we devised a couple experiments to validate assumptions against our broader audience. The results were instrumental in shaping the features included in the eventual rebuild. The experiments were run on the legacy tools in a way which minimized design and development effort.

1. Limiting the number of available social networks shouldn’t have a negative effect on usage and retention. 

Maintaining and supporting 120+ social network integrations had a taxing effect on the codebase, and created additional design work as well. Feedback from publishers indicated they were only interested the in top networks, and actual usage data back it up. Most site visitors were only sharing via the top 10 social networks, with the shares via other networks falling off rapidly the further down the list you got. The list was culled to 24 networks. Over the course of the experiment, no change in usage or retention was noted.

2. Simple visual improvements + code optimization would boost retention.  

In addition to validating the assumption that improving the visual design of the buttons would boost retention, this test modernized the codebase that deployed the legacy buttons across millions of publisher sites. In the end, when the assumption was validated, the retina ready buttons and refactored codebase were rolled out across the entire network of legacy share buttons.

The chosen few

Design

Simplifying the configuration process

A recurring piece of publisher feedback was that the configuration process was too complicated. The first step required a user to choose their platform. The overwhelming majority opted for a standard javascript install (called website… wait a second, aren’t they all websites? ¯\_(ツ)_/¯ ). The next most popular type of installation was via the WordPress plugin. The remaining choices were so seldom used, and could leverage a standard install that they were removed from the choices.

To further simplify the the process, I split the six types of legacy share buttons into one of two broader categories: inline buttons (where the buttons are placed inline on a page, and scroll with the content) or sticky buttons (where the buttons stick to one edge of a site visitor’s browser.) Any additional configuration options such as the display of share counts, button shape and size, or calls to to action could be applied after the primary button type had been selected.

The result condensed the first two steps into one, and reduced the choices from 11 to three (inline, sticky, or WordPress) without loosing major functionality.

Three choices: Inline, sticky or WordPress

Exploring design options

In an effort to minimize scope, and keep the re-design as close to the original experience as practically possible, I chose to focus design exploration on the most popular legacy share button type: the chiclet.

I designed a number of presets that expanded on the basic chiclet style and placed them adjacent to UI inputs that would be required to create the preset. The ultimate goal was reducing the number of UI inputs while maximizing the potential options for customization.

We also decided to leverage an an open source pattern library (materializecss.com) to further expedite design and development.

Tying it all together

Once we were satisfied we could enable a reasonable amount of customization without overwhelming a user, (or a developer) I produced three unique on-boarding flows. Each flow presented the customization options in a unique way. One was based off an on-boarding flow we liked from an unrelated product, another was similar to a direct competitor, and the last was completely unique.

Quick comps were produced in sketch, then prototyped with InVision. We tested the prototypes against internal and external users. Version three was the clear winner. It tested best against users with limited tech know-how, aligning well with our primary persona “The little guy”. More savy users still found an acceptable level of customization.

Take the InVision prototypes for a test drive

 

Version 01

Version 02

Version 03

High fidelity prototyping

With our sites set on version three, I created higher fidelity prototypes using Origami Studio. The prototypes focused on the configuration screen, as well as the behavior of the buttons on a publishers page. The prototypes helped further refine the interaction design, and helped communicate  subtle design and animation concepts to the development team that are typically lost in translation. They greatly reducing the back and forth required to execute. I also further simplified and consolidated the UI inputs required to create the desired level of customization.

Share button configuration

Interactions and animations

Sticky buttons

On hover animation, hide/show toggle, and responsive behavior

Desktop inline button behavior

Mobile inline button behavior

Take the Origami Studio prototypes for a test drive

Download and extract the .zip file. Run the extracted file in Origami Studio.  ShareButtonConfig.zip
Download and extract the .zip file. Run the extracted file in Origami Studio. StickyButtons.zip

A final sanity check

With the experience built, we ran a few final tests on usertesting.com to ensure we hadn’t inadvertently overlooked any aspect of the experience.

UserTesting.com

Launch

The new on boarding experience and buttons were initially made available to a limited number of visitors. We installed fullstory to monitor usage in real time and respond to any bugs or hiccups we saw people encounter. Fullstory had the added benefit of turning our otherwise mundane launch into a into a Super Bowl party. Team members from across the company, inside and outside of product and engineering huddled around a big screen, cheering people on as they navigated our new experience. Mountains of terrific insight were captured in the process, and brought any gaps in the experience into sharp focus.

Fullstory

Post launch

Getting more code on the page

The largest hurdle standing between a new publisher and shiny share buttons on their site is deploying the code to their pages. Shortly after launching the new on-boarding process, we observed people struggling. We used an image to show people where to install the code in the header of their site, complete with a big juicy “paste here” arrow. Unfortunately some folks took that quite literally, and repeatedly attempted to paste the code on the image. I redesigned the “Get the code” page to be more explicit, and removed the confusing image.

Doh!

Revamped “Get the code” screen

Verifying an installation

When a publisher copied the code at the end of the legacy share button on-boarding process, their interaction with ShareThis was over. Wanting to avoid the same dead end, the new buttons were rolled into a platform that had recently been built for another ShareThis tool. The platform provided us the opportunity to further engage publishers once they were done with their initial configuration.

In an effort to boost the number of publishers completing the installation process, we created a process on the platform for publishers to verify the installation of our javascript on their sites. To begin, I designed a process flow in conjunction with our engineering team to outline the various steps needed to complete the verification.

ShareThis JS verification flow

After laying out the process flow, I comped up screens in sketch, and imported them to InVision for prototyping.

Sketch comps for InVision prototype

Take the InVision prototype for a test drive

 

ShareThis JS verification

The two month period post deployment saw a 20% increase in additional domains day over day. In the same period, the network saw a 98.8% increase in additional pageviews week over week.

Epilogue

The share button re-design been an overwhelming success. Less than 10% of people who started configuring the legacy share buttons  ended up registering an account. The new experience increased the percentage to over 30.  Over half of legacy button users would removed the code from their pages within 24 hours. The new buttons brought that number below 10%.

More

ShareThis Share Buttons

ShareThis Share Buttons

ShareThis Audience Builder

ShareThis Audience Builder

Coastline Android App

Coastline Android App

ShareThis Brand Guidelines

ShareThis Brand Guidelines

Coastline Promo Video

Coastline Promo Video

ShareThis Interactive Prototyping

ShareThis Interactive Prototyping

For The Win!

For The Win!

Cropt

Cropt

USA TODAY Bracket Challenge

USA TODAY Bracket Challenge

MMA Junkie App

MMA Junkie App

Fantasy Score

Fantasy Score

Ski Time!

Ski Time!

Rincon Drone Sessions