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.

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.

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.

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.

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.

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.

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”.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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%.