Internship | Front-end Developer | Fall 2017
During my time at Shopify, I worked as a front-end developer on the Social Channels team, working with designers, some PM folks, and other developers to improve the merchant experience of selling products through different social channels. We wanted to optimize UX flows and make the user journey consistent across all social sales channels.
For the first half of my internship, I shipped incremental feature changes to the Facebook, Messenger, and Pinterest channels’ merchant dashboards, focused on improving the merchant experience during the influx of Black Friday Cyber Monday sales. During the second half, I wanted to take on more of an product ownership role, and championed the redesign of a feature on the Facebook channel from cradle to grave.
As a team, our mandate was to make the merchant’s experience of selling on Facebook, Pinterest, and Messenger intuitive, consistent, and efficient. Just to give a bit of Shopify context, You can use Shopify to sell your products online in an online store, on social media and online marketplaces, and using other online sales channels. The three primary channels I worked on:
- Facebook lets merchants sell products on their Facebook page
- Pinterest turns Pins of products int Buyable Pins
- Messenger lets merchants sell products through chat
Project: Preview Component Redesign.
One of the main features of the Facebook channel is allowing merchants to reorder how they want their collections to appear on Facebook and then previewing how it would look like on Facebook before publishing it for their customers to see. Here is what merchants currently see:
Since we aren’t able to pull Facebook’s ever-changing UI directly, the preview component, which was accurate when it was built, is now not an accurate representation of how their shop actually looks like on Facebook, it doesn’t always behave as expected, and is inconsistent across channel. Without aligning with the merchant’s mental map, the component interrupts the merchant’s workflow and erodes merchant trust.
Facebook’s hard-coded preview raises a bigger issue of how do we present accurate previews across channels. Since we aren’t able to pull directly off these platforms, a significant amount of resources would need to be dedicated to maintaining all previews whenever any of these platforms makes a change to their UI. The UI patterns used are showing their age and inability to scale past a certain complexity.
Why is this worth solving?
It was important to me that we were spending the right amount of time and resources on a feature that would impact merchants and align with Shopify’s company goals/product priorities. We shouldn’t be “setting and forgetting” our channels, and should be consistently working to maintain (and raise) our merchants’ trust. They should not be getting used to a bad component, expecting it to be inaccurate/broken.
Addressing Facebook’s preview component first will set a standard for how previews should be handled across channels, consistent layout and level of accuracy, even they don’t use the same component.
Our north star metrics are accuracy and consistency. These goals will be measured as follows:
- Preview component reflects what is on Facebook or it’s clear that the design isn’t meant to be a one-to-one representation
- Works on desktop and mobile
- If merchant is not able to see their preview, or View on Facebook, or if their shop/page hasn’t yet been approved, or any related error, they should know what’s wrong and the steps to solving it (even if that’s just waiting)
- Merchants should understand the purpose of the preview component (and the purpose of the page by the page name) right away, and each action should match the merchant’s mental model
- Lower incidences of merchants asking support why their Facebook is not updated yet, or why the preview doesn’t look right, or any preview related concerns
- Increase engagement with the component
- Have a help doc that can answer all those questions and explain how the preview component behaves, including what we control and what Facebook’s algorithms control
To make a data-driven decision, I wanted to first explore how the current preview component was being used, seeing where merchants were clicking and how many merchants were using each action on the page. From the data, it was clear that the Cancel button was not being used on the current UI, and would potentially justify removing it in the new UI. It also showed that merchants were toggling between mobile and desktop views, and we could not remove one or make it default to the device the merchant was on.
Most importantly, it showed us that we couldn’t burn the page component completely because people were using it!
During the initial sprint, we outlined the user’s journey, mapped out the questions they could potentially ask at each stage to understand their pain points. Then chose 6 key merchant questions to focus on and made low fidelity sketches that are meant to solve those merchant questions.
The first iteration of the design was to include the preview in a modal. Within that modal, merchants would be able to publish changes, and toggle between desktop and mobile. On mobile, preview would swipe left to a new preview page instead of a modal and to make more changes the merchant would swipe right to navigate back.
- The design would be responsive on both desktop and mobile.
- Both views can be accessed through all devices — previews that don’t fit on the viewport can be viewed with side scroll
- The preview would still need to be hard coded in, which means resources would need to be put in to maintain the component to look like Facebook’s UI
- This means that there will be periods of inaccuracy and since we can’t exactly replicate Facebook’s UI, the design is not abstract enough to be an abstract representation and not accurate enough to be a one-to-one preview.
After exploring options down to how many dots the draggable icon should have, the final design took an abstract route. This was a tradeoff the team decided to take: to sacrifice one-to-one accuracy in order to not require constant maintenance of the component. This way, merchants know not to expect what they see on the page to represent their Facebook page exactly.
To tailor to new merchants and merchants who are unfamiliar with the feature, it may be a good idea to include a help docs link in the component that includes screenshots explaining what would happen on the Facebook side when they reorder their collections. This is much more scalable because when Facebook changes their UI, all we would need to do is change the screenshot.
Since almost all other sales channels have some sort of preview component, the next step is the aim for consistency across channels by adopting a similar pattern to this one.