Gatsby Publish
Gatsby Publish is an exploration of collaboration for content previewing
sites with Gatsby powered framework.
Gatsby Publish
GOAL
To design a collection of reusable components guided by principles that can be used to create simple and complex experiences. Optimized for e-commerce, it’s used to build internal and customer facing software, that maintains a consistent visual language across all company platforms.
MY ROLE
I paired with another designer on the design system refresh. I also partnered with our Lead front end developer to oversee quality during the implementation process.
The Problem
Business Problem
While many customers utilize Preview in their workflow, often customers experience performance problems, which in turn has created a distrust for the preview product. We needed to find ways in development to improve the reliability of Preview, as it’s a huge selling point for the product.
Customer Painpoints
When content editors run into problems with preview, they turn to developers to troubleshoot. The frequent shoulder tapping, is disruptive to their workflow and doesn’t provide them with complete ownership over their process.
When content editors opened their preview to see the live version of their site, they are met with very little communication and insight into the process of their preview.
How might we... give users feedback and insights into the status of their Preview
While the development team worked to improve the speed of preview, I focused on understanding how content editors and developers worked within preview.
The MVP
Content editors respond best to non-technical jargon, and just want to be guided when previews aren’t working as they should.
Introducing a widget that communicates page status, a preview link to share, and an edit button that brings users back to the CMS for quick editing.
Content Editors responded well to the widget, and even better to the improved speed of previews, but they still craved more out of the experience.
To keep Gatsby ahead of competition like Netlify, or Next.js, we wanted to explore what problems we could solve for Content editors and developers within the integrations part of the Gatsby workflow.
We know that Content Editors are shuffling between tools and that getting feedback on sites before going live is a pain point with little process.
The final step for getting feedback, making edits and getting a site published shapes the last 20% of a workflow, but it often feels as if it takes longer. This space is an opportunity for us to improve the user experience.
How might we... Provide a preview experience that ties together Content Editor’s workflows
Interviews
Content Editor, When I gather feedback I often share it in various channels and ping people directly. And the CEO just takes screenshots and scribbles feedback
Content Editor, I don’t have a process for getting feedback. It’s just really all over the place
Developer, Designers give me feedback like change the padding or let’s change this functionality
I exploring a higher fidelity design focusing on giving feedback directly to a site Preview. Then I iterated on the design based on user needs. Adding improved functionality like the ability to highlight text to give specific feedback.
Focusing on Feedback
To start, I quickly mocked up wireframes that allowed editors to share feedback directly on the preview they were viewing. I wanted to get this in front of content editors to see if this provided this aligned with the feedback we were hearing from them.
Establishing product priorities
As I designed a richer UI by taking feedback from Content Editors and Developers to see how the experience could potentially come together.
The design expanded to included a robust commenting/tagging, the ability to view code and give feedback on , versioning, and a faster way to get to content in the CMS from Preview.
Outcomes
A well researched design
A lot of research and testing was put into this project. Giving my product team options to break down this work and establish the correct priorities.
A shift of focus to Backend Performance
In the end, team shifted from frontend to a backend performance. This left much of this work untouched, but available to be picked up when the time was right.
This project only made it to the MVP stage, and that’s okay. Design is also be the practice of making sure we build the right things at the right time.