Popup Builder Redesign
Postscript
Background & Objectives
Have you ever been shopping on a website and had a popup appear saying that you can subscribe to texts and emails to get a discount? Popups like that are a significant way Shopify merchants grow their subscriber lists, and having a intuitive and effective way to create these popups is something they look for when choosing a marketing platform.
The objectives of this project were twofold:
Understand the pain points and limitations of the current popup builder and create a better popup creation experience for customers
When customers create popups with the new editor, those popups should perform better than our previous popups
Role
I was the sole designer for the discovery and design phase of this project, working with a product manager and engineering team. I also conducted user research by interviewing customers and internal customer support specialists both for both problem discovery and usability.
Initial Research
I had worked on the List Growth team at Postscript previously, who owned this feature, and feedback around the existing popup editor had come up in my conversations with customers over that time. Even with this background, prior to beginning ideation on the new editor I interviewed several customers and internal customer support specialists about how the existing editor was (and wasn’t) working for users.
I heard a lot of the same things over and over, and boiled down the needs to a few major asks:
“I want the popup to look like it belongs on my site” aka customization for branding and design flexibility
“I want to be able to edit this myself and get the result I want” aka simple interface without the need for custom CSS
“I want to be able to add more steps to my popup, like a micro yes intro step” aka allow for adding more steps and flexible navigation of the popup
Users also wanted features like spin-to-win, dates, and others that would be difficult to add into our existing popup editor because of its rigid design and brittle codebase.
Competitive Analysis, Sketching, and Ideation
In a case where there are already major players in an existing product landscape, my process includes doing some competitive analysis as part of my initial ideating and sketching phase. This can help identify patterns that may already be familiar to users, or find gaps in the existing product offerings out there. In my research calls, a few players in the space had been referenced, so I checked those out, as well as some editor WYSIWYG style software that isn’t directly related to popup building.
Early conversations around how the team would build this new editor began around the question of building on top of what we already had, or starting from the ground up with a complete rewrite. Part of my early vision work’s purpose was to showcase the features users were looking for, and to give the engineers an idea of what might be required going forward to help inform their decision on the codebase. Another purpose of that work was driving alignment across the team and leadership.
Below are some mid-fidelity wireframes that were used in early vision work for this project:
The mockups above were used to tell a story of how users could create popups using their existing brand assets (fonts, colors, logo, images) using a wizard, template, or generating via AI. These helped drive the conversation of where we wanted to go, and let me explore some visual and structural ideas for the design.
There are some patterns here that were explored and moved away from, like a canvas-style editor workspace and two editor panels, in the name of keeping things simple for marketers who are less familiar with tools like Figma.
After we decided to rebuild the popup editor, I started to map out the flow of creating and editing a popup, as well as some more detailed wireframes of how certain functionality would work. There are just a few examples above.
To address the needs of branding customization and simplicity, I went with a WYSIWYG style editor that gave users more options for customization than the existing product had. Elements could be rearranged, and many of their visual properties could be adjusted with an intuitive UI that mapped to CSS properties. This largely solved for the needs of increased customization options, although there is still more to add as we continue iterating and improving on the editor.
Planning, Prioritizing, and Getting to Beta
Pictured here is our wild, wild story map in FigJam. My product manager, engineering manager, and I spent a lot of time collaborating here, where we audited existing functionality and planned out additional functionality for the redesign. This was a very helpful tool because we were able to clearly plot out which features needed to be completed by which phase of the project.
Consider this the remote-first version of a whiteboard covered in post-its. 😅
This work was translated into Notion docs for different bodies of work that corresponded to releases and/or features, which were easier to follow, but this was our main team workspace for figuring out messy things.
Once I had a design I felt was on the right track, I wanted to validate the design with users. I started with a Figma prototype, and once I gained confidence from testing that with internal customer support specialists and customers, the engineers got some core functionality working in an alpha environment, and we ran another round of tests. In both sets of tests, I talked with several people, asking them their thoughts on the interface overall and to do a few tasks in the editor. There were some definitive learnings that came out of this testing, the largest of which were:
We needed a template library sooner rather than later.
It was not going to be ideal to have users to start “from scratch.” Instead, it would set them up better for success to give them a template to start from.
We needed to be more clear about what I had been calling “shared styles” (and now are called “theme styles”), and default to editing them vs one-off changes.
The term “theme” resonated way more with these users than “shared styles.”
When a user changed one primary button color, for example, they expected that color to change on every step of the popup.
My team aligned with leadership on what to prioritize for our beta launch, which aimed to get customers using our new popups ahead of the winter holiday season. This time is generally one of the busiest of the year for ecommerce merchants collecting subscribers, and since our new popups were testing better than the existing popups, we wanted customers using them for this busy season.
Some screens from the prototype that was tested
Moving Pieces
There are so many moving pieces within the popup experience, and I wanted to show some of the UI here for various panels and states of the product. I am supporting my team in improving the editor on ongoing cadence. We are following through on our longterm roadmap, in addition to working in customer feedback on a priority basis.
I am also looking at improving our reporting and analytics on popups, which I have not delved into here. I have conducted several research interviews with customers and customer support folks, and am working to define the biggest problems to solve and make some suggestions on how to solve them.
I mentioned the need for templates above and, as part of launching beta, I designed 14 templates for users to get started with. I used assets that our branding team had made (placeholder logos and imagery) to help bring these layouts to life. I looked at common design patterns for popups (side image, fullscreen, no image, etc) and made sure to include options of for those common layouts. These templates are available in the product now.
Results
As of this writing, about 70% of Postscript customers who use in-house popups have moved to the new popup format, and the team is making plans for a migration later in the year for those customers that remain on legacy popups.
The new popups are generally performing around 30%–40% better than the legacy popups. We think this is because of the flexibility the new editor offers for strategic moves like including an intro step, or “micro-yes” (the addition of an intro step alone can boost opt-ins by 20%–30%), as well as more robust design capabilities.
These numbers are in line with our team’s goals, but of course we want to push them further.
As far as the user experience, many users are able to make the design changes they want to without needing to contact our team or relying on custom CSS. That being said, the team does get feature requests often for things that are on our roadmap, like enhanced targeting, a countdown timer, and additional triggering options.
Keep an eye out for more projects that detail enhancements to the editor!
Here’s the marketing site for Postscript popups where some of the latest metrics will be.
Thanks for reading this far! This was a long one. 😮💨✌🏻