CASE STUDY
Building a better site builder,
Phase 2
—
We structured ourselves
for proximity to user.
Another decision we made was to assign our small product team 100% of customer support duties. We had the resources to hire someone to manage this communication, but proximity to our users was, and still is, a primary concern. While that sounds like a lot to ask - the insight it provided was invaluable.
—Our team found that the best Learnings were derived between the lines during daily communication with our members in the context of customer support.
Our users drove
the early roadmap.
While we had a strong idea of where we wanted to take the Site Builder - we allowed customer support feedback to drive the first 6 months of our roadmap.I honestly believe this process of directly communicating with our users took a good idea and made it into a great product. Clearly, this is not right in most situation, but for our small team we started making better product decisions when we aligned ourselves more closely to our users.
—For us, thinking outside of the box with our operations and focusing on a close proximity to our users turned into a big product win.
LESSON #324
Templates of templates,
of templates
—
Staying
template free.
The situation — we set out to solve two common customer support requests: • I need 5 different pages, all setup exactly like this page, can you do that for me?
• I need a backup of a page, so I can use it later.
Our first inclination was that we need to create a system of templates.
However, the overhead of creating a system for parent-child templates was extensive.
| Potential flows: 1. Save template 2. Browse templates 3. Create page from template 4. Update template from page 5. Edit template directly | Downsides to templates 1. Templates are locked in time (or require manual updating before use) 2. Requires interface to select, update and edit 3. Lots of backend overhead to keep separate from actual pages |
We circled back
to the users.
After further investigation, the desired action was either: “I need a page copied” or
“I need a page backed up”
Both were essentially a copy or clone action. We knew it had to be page-type agnostic and we wanted to avoid the overhead of a template management system.
Clones,
not templates.
Instead of a complex system to manage templates we built a new way to create a page: Clone page.Every page
became a templates.
With the Clone Page approach, every page became a live template that could be replicated. This approach had low technical overhead - we were already using this method to replicate the site themes and starter menus.
Epic.
But, not a slam-dunk.
On our first pass we missed something important. While we had made a simple and highly useful solution to the problems we identified, we needed to give one major paradigm more consideration: Shared Stories.
Let’s dive in —
Pages are specific to a website and have a layout profile. A page can reference a story.Stories belong to a central archive and have a sharing status which applies to the network. When viewed on the network the layout is standardized.
A story can be assigned to a page and is displayed according to the pages layout profile.
We determined that we would always be cloning a page for its layout profile. But, the operation with the associated Story, needed further consideration.
Clong page, then:
We developed
a new set of options.
We determined the best approach was to let the user decide between creating a Clean New Story or Reference the Current Story.
Not only did this provided additional affordance it provided clarity on how the story would be handled during the page clone process.
Here's the next step:
A success.
The feature received positive feedback and has become a central pillar to the site builder.