Page Builder & Theming
Role
Lead Designer
Timeline
3 Months
Team
1 Designer, 1 PM, 3 Developers
Background
This project started as a mission to build a design system that would empower clients and design contractors to theme e-commerce pages with a range of styling options, allowing them greater control and relieving our dev team of those update requests.
As the project proceeded through discovery and early iterations, we realized this could be an opportunity to solve a bigger-picture problem if we could get buy-in to thoughtfully expand the project. Rather than a new design system, we decided to create new tooling that would allow clients to not only theme, but create their own no-code site on our platform, with a simple experience for all skill levels, and nuanced features that continued to provide industry-specific solutions our clients came to us for.
Challenges
Themes
How do we create a design system for use by:
Internal designers
Remote contracted designers
Multiple clients with respective brands
Page Builder
How do we create a builder for clients who:
Can't read/write code
Have unique business cases
May not have an inherent eye for design
Starting with Themes
Design systems and theming are never as simple as they seem. Most systems are created to support a single entity that’s only focused on its own branding. In our case, we weren’t only concerned with our own, but the respective branding of our client base, as well.
We needed to create one system to satisfy a branded house that was also a house of brands.
Our main users were internal designers, contracted designers, and our clients.
Our solution was to create a variables library with 3 layers for utility. We broke those down into:
Lv1: Primitive Tokens
The properties and values that exist within designs
-
Definitions for every property across multiple systems as the base for semantic tokens
-
Reference-only outside of Blueport’s internal design team for security
5A6D72 100%
Pine/0
Value
Primitive Token
Lv2: Semantic Tokens
Context on how the token should be used i.e. “surface/primary”
-
Tailored to specific clients, so different clients can draw from the same primitive if necessary
5A6D72 100%
Pine/0
Surface/Primary
Value
Primitive Token
Semantic Token
Lv3: Component-specific Tokens
Where a semantic token is applied to style a component i.e. “button/primary/surface”
5A6D72 100%
Pine/0
Surface/Primary
Button/Primary/Surface
Value
Primitive Token
Semantic Token
Component Token
Stroke/Primary
Button/Secondary/Stroke
Add to cart
5A6D72 100%
Pine/0
Surface/Primary
Button/Primary/Surface
Add to cart
Value
Primitive Token
Semantic Token
Component Token
This system tested the rigors of our business needs well. Internal design would have control of the primitives, while contractors and clients would have access and control to their respective semantics. However, with Blueport sailing toward a new SaaS identity, this tool didn’t feel like enough.
How much further we could push all of our ideation-phase innovations? Could we use this ideation to launch us into a new flagship product?
That’s when it occurred to us: a new design system solved some of our problems as a company that operated like an agency, but to better serve our clients and ourselves, we could go bigger and create tools that would go beyond self-styling; we could allow our clients to not only theme, but build completely on their own.
What about buy-in? Expanding scope and pushing deadlines isn’t ideal, but when you have an idea you believe will push the needle, and data to back it up, it becomes a realistic pitch. Together with the lead PM, we organized our concept and briefed the executive team on what we wanted to do, what it would cost, and why it was worth it. Fortunately it was a natural extension of what we were already doing, and the benefits were obvious.
The Page Builder
The goal for theming still persisted, but going forward we were going to back it into the platform as feature with its own interface that worked in concert with our new page builder concept, both of which would have their own intuitive interfaces in the same platform.
Fortunately we’d already accumulated a large and well-documented amount of feedback over the last year from our customer base regarding where they’d like to see our platform go and the features that would be useful to them.
For the page builder to succeed at MVP, we needed to build
-
An intuitive no-code interface
-
A suite of page elements our clients depend on, including industry-specific solutions that differentiate us from the general e-comm landscape
-
Controls to easily re-arrange page elements
-
Full row and column control
-
Toggles between responsive viewpoints
-
The ability to view the page through certain dates to validate promotion design
-
APIs and fields to call hosted elements, such as images from our database
-
The ability to toggle between the builder and theming on the same page
Early concepts for the theming companion interface
WIP as we explored the look and feel of the page builder interface
Everything was responsive and every selection would dynamically adapt your menu’s options
The Page Builder realized
Of what I’m able to show you, this last image is part of our fully realized MVP. We successfully implemented all of our requirements, and were able to take it a step further with an AI tool that would allow the user to build in a similar vein as Figma Make.
Impact & Results
This is a freshly launched product being rolled out on a client-by-client basis until it reaches full adoption.
75%
Faster client implementation rate
Previously, our clients took months to implement and onboard. Our first client to join the platform through this process was implemented in a quarter of the time due to all of the development costs being removed from the process.
100%
ARR growth positioning
The Page Builder tool is becoming Blueport’s flagship product in their new SaaS identity. As such, it has become a focal point of sales demos and generated exponential potential client interest, leading our sales forecast to estimate doubling our annual recurring revenue.