Case Study: Social Media Posting



Our platform on iOS, Android and responsive web had many public faces, each of which served as the official social media presence for a major brand.

But users who downloaded our Major League Baseball app were very different, at least on the surface, from the tight knit community that loved the metal band Slipknot, who in turn were different from Pakistani Cricket players or fans of the LA Kings.

Because our base functionality was by necessity the same across these disparate communities, we looked for ways to delight our customers and improve the experience of our platform through fundamental changes that would be relevant across a worldwide audience.

The Problem

I realized that posting success (whether a user successfully posted after clicking the post button) was bad. So shockingly bad in fact that at first I thought it must be an error.
Posting success averaged across brands: ~11%

It wasn't an error.

The Understanding

However, by diving into the stats I realized that if we only looked at users who had already posted at least once, the posting success was actually pretty decent.

This told us that initial users were pressing the post button out of curiosity and then deciding not to post, either because they didn’t know how or because they didn’t know what to post. User testing indicated that the latter issue was likely the bigger problem.
We also knew from our stats that users who successfully posted at least once were much more likely to become regular productive members of the community.

Therefore, the question became, how do we...


an improved posting experience


A wide variety of fans from all walks of life


Easily and simply post photos, video or text, in a fun creative fashion.

And improve…

Their longterm connection to the community of which they are a part.

The Process:

After a developer spike to investigate the issue from a technical standpoint, our cross functional team met to discuss options and decided to adopt a photo manipulation package for our app, which would give users a huge set of options for expressing themselves creatively at a cost that would be far less than developing it ourselves.

As the product manager for UX & UI, I gave one of our designers the job of defining the initial filter set for our package (with input from the entire company) and formatting them as needed for our various applications. The initial feature set would be optimized and tested on a brand by brand basis as time went on.

I took on the task of improving the posting experience from a UX & UI standpoint.

The original state

UX & UI Design Goals

I knew from user testing and analytics that we had issues with our current functionality. New users were not immediately sure where to access their photos, the opening screen was focused primarily on text, and the experience of adding a photo was confusing, because the newly attached graphic took over most of the screen.
In addition, though the location of the post button was ‘iOS standard’, it could be in a more intuitive position. (Just because Instagram does it doesn’t make it right.)

My goals for the project became...

  • Create an intuitive, simple experience for the user.
  • Don’t clutter the view with functionality that isn’t needed for the task at hand.
  • Graphically depict the hierarchy of functionality appropriately.
  • Allow for not only the new digital feature set but potential future expansions.
  • Don’t be constrained by ‘industry standard’ design elements if they can be improved upon.
  • Potentially lead the way to a new design esthetic that can in a subtle, piecemeal fashion affect the rest of the app (In other words, be aware of existing design constraints but have an eye to changing those that can be improved.)
  • Design for the lazy user, but make power user options available.


Sketch, InVision, paper

Initial Work

Now I knew from past projects that, in our organization, making a fundamental change to UX or UI was difficult, because no matter how ‘improvable’ the existing experience might be, there was always the ever-present fear that something might make it worse. In addition, we’d gotten blowback from our brands in the past when making changes without consulting them. Consequently, I knew I would have to approach any changes delicately and get buy in from Engineering, Management, Customer Engagement, and my fellow designers if I hoped to avoid opprobrium.
Consequently I created a series of prototypes from most to least radical as a means of testing the waters for a willingness to change. For the initial work, I relied on input from the two designers on my team, members of our Customer Engagement team and most importantly the head of Engineering who was also head of Product. His support would be essential if anything at all was to happen. Using their feedback, I fleshed my designs out visually in Sketch and InVision and set up a meeting of all stakeholders to present both the problem and my potential solutions.
Each stakeholder had strong opinions, but by teeing up each design as a solution to an agreed-upon set of problems, we were able to address issues collectively without getting too far in the weeds. The support of Engineering was essential in convincing our CEO of the need for significant change, and I left the meeting with provisional approval for a path forward. In fact, with a few minor changes, it was the design I felt most strongly about. By intentionally presenting a series of solutions along the spectrum of most to least radical, I was able to get our group to see that what we hoped to do was firmly in the sweet spot where users would be delighted by the experience but not bewildered. (At this point the mocks were in full graphic color, which I knew from past experience was necessary so that none of the stakeholders derail the meeting by confusing UX for UI.)
After more iterations and feedback, we had a sign off meeting for the stakeholders. This meant that I was free to move forward with the design.

Design & Document

Sketch, InVision, Confluence, JIRA

Finalizing the Design

I fleshed out the details of the Sketch File as needed for mobile and tablet, exported it to Zepplin for the developers, and wrote the Confluence PRD and the JIRA ticket that referenced it. As part of this process I defined, with input from Engineering, what success for this project would mean in terms of analytics. Technical details as appropriate were supplied by the head of Engineering, who was responsible for parcelling out the technical tickets as needed, and the project was added to our upcoming sprint.
By this time, the other half of the project, adopting a third party filter set for use during post, was ready to be implemented thanks to the other designers and developers. Because I had kept everyone apprised of the status of our project at our cross-functional sprints, no one was caught by surprise.
As it was being implemented in iOS and Android, I met regularly with the developers to answer any questions that came up, as did the other designers. There were a few minor design tweaks that needed to be made, thanks to the exigencies of iOS & Android, but we worked them out in the moment with sign off from the head of Engineering, as needed.
After completion, our developers gave progress demos to the entire company at our end of sprint demos, and all were merry.