Shogun 2022/2023
The problem & context
Shogun is an ecommerce experience platform empowering brands to drive higher conversions, revenue, and brand loyalty. Shogun Page Builder and Shogun Frontend help teams build and optimize their online stores to deliver exceptional experiences.
Frontend is a low-code platform, which means you need as a user to have at least a basic knowledge of frontend technologies to be able to modify the layout of your ecommerce store's section, either through Frontend’s IDE or local development environment. The advantage of having your e-commerce store built on Frontend would be leveraging the headless technology to increase the rendering speed of your store and therefore increase conversion.
Page Builder on the other hand is a no-code drag&drop platform, where non-technical users are empowered to create and make layout changes directly through the no-code editor.
Clients would usually use an external agency for the low-code environment to develop the components and sections needed for their storefront. While this environment was great for tech-savvy users, non-technical users would have to ask for a developer’s help to make any type of layout creation or change.
This is where Page Builder’s offering came in, where you could leverage Page Builder’s no-code capabilities to build layouts as a non-technical user and therefore significantly reduce the barrier to entry and the cost (and time) of implementation.
The role & team
As a senior product designer for this project, I led all design initatives and played a significant role in defining the different milestones for implementation through envisioning different types of approaches to the problem.
The team included the project's product manager, engineering team, user researcher, and me as the lead product designer.
Research & initial steps
After having calls with customers, a couple of reocurring needs surfaced that validated the need for a visual editor integration such as: flexibility over design capabilities, wanting more control over their designs and wanting to automate the process of implementation more.
Kick-off
After the product discovery phase and validating the need, I set out to organise a workshop with the internal design team to kick-off the project by doing a crit of an initial approach and flow I proposed and align together on possible routes.
Explorations & defining milestones
After the initial steps taken, I started off by putting together the flow for an ideal state of what it would mean to fully integrate Page Builder's no-code editor into the Frontend product and reverse engineer the milestones based on this artifact together with the engineering team to discuss feasiblity and realistic milestones. In an ideal world we wanted Page Builder's editor to be part of a seamless experience when you would create a section. That meant the ability to directly login to Frontend as a user and directly access Page Builder's no-code editor through the Frontend platform.
Challenges
Integrating another product’s editor in a different ecosystem is a huge endeavour in itself. How could we approach this in such a way that we can realistically ship increments of value to our users? Due to time constraints & resources, we had to discuss ways we could leverage Page Builder's functionality as soon as possible. This meant still keeping them as separate editors in the beginning.
This resulted into breaking it down into two milestones based on feasibility.
1. First milestone consisted in communicating with Page Builder editor under the same Frontend account.
2. Second milestone consisted in integrating Page Builder editor inside the Frontend platform.
Results
By releasing the first milestone, this enabled non-technical users to build pages without needing help from developers. Usage for the Frontend product grew by 10% and already existing customers were able to let non-technical members of their team create and make changes to pages directly.
Want to connect? Drop me a line on linkedin.
