A prototyping tool that capacitates ATTN:'s editorial team and agency arm to preview content on simulated social media feeds
— THE PROBLEM
ATTN: is a media company housing an editorial team as well as an agency arm that works with third party brands to create short- and medium-form video content.
Media production teams at ATTN: have no way to gauge the efficacy of the visual or written details such as captions that accompany video content uploaded to Facebook as details to promote high engagement on the posts; nor do they have a way to demonstrate prototypes of rough, fine, and final cuts of videos for third party clients.
— THE SOLUTION
Product Design would create a prototyping tool specifically for the media production teams to preview their video cuts for both internal decision-making and client preview purposes. A prototyping tool would:
True View’s research was largely based in the Internal Personas library I aggregated about a month prior to the launch of this project, as well as on insights gathered from Google Analytics regarding Audience behavior for branded video content. Some realizations we made from those sources were:
Each video would have different requirements, such as a thumb, a caption, a pinned comment linking to a third party website, or a “handshake” (Facebook’s term for a brand call-out), and because stakeholders were interested in testing each of these components separately, none could be required
Because of the structure and delegation of responsibilities on ATTN:’s product team, the PM on True View took lead on writing User Stories, which I then refined. Some key stories included:
As a user, I want to upload a video cut to a simulated social media feed
As a user, I want to share my prototype with a third party
As a user, I want to create a new prototype
As a user, I want to view the simulated prototype on my phone
Once research and user stories were completed, I started in on sketching out testable solutions. One difficulty I faced was that we wanted to include a large number of options for the users to test, but didn’t want the prototype to scroll out of site in order to access those options.
Of the sketches that I tried out initially, I was primarily interested with testing both a drawer solution as well as a solution allowing the user to tap into the area of the prototype they wanted to edit and change elements locally.
Eventually though, and after receiving design feedback on some various solutions, I decided to move forward with a slide-out drawer on the left side of the screen that could expand or contract depending on whether or not the user wanted to see their in-process prototype in an isolated view.
My team and I embarked upon many sketching sessions to brainstorm possible solutions
Wires of the MVP design
In addition to wiring the actual editing tool, I needed to replicate Facebook's feed as it currently existed, in order to create an environment in which a user's post could be previewed. Initially, the feed was meant to appear as a wire, as the tool's primary use would first be to preview different elements of a hypothetical post, with the plan being to upgrade the Facebook wire later on to a mock or imported feed in next versions.
Wires of Facebook's feed as it existed in January 2018
Wireframing the Facebook feed and handing off svgs to the developers, as opposed to importing a live feed into the app, was hugely beneficial in that it allowed us to implement some further design solutions and have full control over them, such as the ability to display a post on top vs. mixed into the feed randomly.
With wires in hand, I presented my solution to stakeholders. The response was positive, as they found the drawer solution to be an intuitive way to display the editing tools. With this approval, I designed high fidelity mocks, utilizing the ATTN: Pattern Library to guide these designs, so as to maintain coherency among ATTN: products.
MVP final mocks
Once all the mocks were completed in adherence with the Pattern Library, I built a prototype in Invision in order to gather feedback, and to hand off to the frontend team.
Once the MVP design had been shipped, I scheduled contextual interviews with some key stakeholders, to get an idea of how intuitive the solution truly was, and how the design could be iterated on.
Design-wise, the response was positive. When asked to complete test tasks, all test subjects could easily navigate to the editing pane, upload the different components of a post, and share with third parties.
However, I did receive feedback that although this solution was good, there were still more features that needed to be included in order to make it truly useful for our stakeholders. Those features included:
These takeaways launched my V1 design iteration and guided us in the next step of features to include
In order to further meet the needs of our stakeholders, I needed to redesign with an expanded set of features in mind. However, I also realized that not all users would be utilizing all features, and that displaying all of them to every user would likely result in cognitive overload and decision paralysis. To avoid this, I decided to split the pane for two different types of users - those who simply wanted to test the content of a post (such as our in-house editorial team) and those who would need to include partnership information.
Wires utilizing our new scale with a 14px base font
We had also received the feedback that features such as turning off the iPhone mock (for partners who dealt primarily with Android devices) as well as being able control whether or not the test post appeared at the top of the feed, would be hugely beneficial. Additionally, some people had a hard time locating the "Share post" button, as it was far removed from the rest of the calls to action.
Finally, redesigning the tool allowed me to implement new features that had changed in our pattern library; specifically, I updated the font sizing. As a team, we had moved from a 16px base font using a Minor 3rd modular scale, to a 14px base font using that same scale. This was a decision that had been specifically made with our internal tools in mind. I was also able to implement updated error states, in order to provide more visual feedback over the course of the experience.
A split pane experience allows different types of users access to the tools they need
Device-less views and more robust error states contribute to a more well-rounded and useful experience
Finally, I created a new Invision prototype to handoff to developers, that now accounted for the updated states as well as any new pattern implimentations.
Some takeaways from working on True View included: