02. The Goal
Create a native content creation tool that allowed our users to build beautiful pages without design or coding expertise.
The problem
The Smartpages tool had lived in a beta state for over two years, with no clear vision of what was needed to make it a viable feature for Highspot’s customers or how to release it to GA.
The team
Product Design Lead (me!), Product Designer, Product Manager, Technical Project Manager, Engineering team of front-end and back-end engineers, including two architect-level engineers
The tools I used
Sketch, Invision, Google Docs, Google Sheets
Original Smartpages Feature – Starting Point
03. Discovery
I was informed that our goal was to refine the Smartpages feature enough to release it to GA. As a startup with a product department of around 40 people and a shortage of Product Managers, I took it upon myself as the design lead to help drive the project forward. My first step was conducting competitive research to see what other products were doing and how we might emulate best practices. Through discussions with our current users, we identified 7 main pain points:
- No way to preview the page on other device sizes.
- Two distinct ways of customizing a block, but the difference was not clear to users.
- No good way to group items horizontally to allow them to stay together on narrower viewports.
- No concept of a “theme” to keep the page’s design consistent and clean.
- No pre-made templates to make creating a Smartpage faster and easier.
- Limited block options that tended to lean heavily on custom blocks, which could lead to responsive problems and difficulty for users who didn’t know how to code.
- No way to copy a specially-styled block for use on the same Smartpage or other Smartpages.
04. The Research
In my opinion, the Smartpages feature was geared more towards web builders who want to create a single page of beautiful content, rather than something like a document. Therefore, I researched other mainstream web builders at the time (Wix, Weebly, and Squarespace). Focusing on the main topics of responsive design, previewing responsive design, full-bleed images, building pages, page-level “themes,” and available blocks, I created a research document presenting the information I had discovered. Using that document, I established our goal for the Smartpages feature: to create an experience that allowed our users to easily create beautiful content without needing to know how to code.
Below are a few sample pages from my research document that we used throughout the process to help us decide what we should be focusing on for feature parity.
05. The Process
I was excited and daunted by the challenge of working on the Smartpages feature, which was complex enough to be its own product. We had our goal agreed upon, and now it was time to execute. There were many different areas that needed improvement:
- Enhancing the ability to preview the Smartpage
- Making the Smartpage responsive out of the box
- Having the right blocks available for our users
- Making those blocks easy to modify
- Making it clear to users where they could drag and drop their blocks on the stage
- Showing the underlying structure of the page
I didn’t want to be a blocker for the engineering team, but we needed an unifying vision. So I created a holistic northstar for what we wanted the Smartpages feature to be. This would help guide us and show that all the individual pieces that needed improvement were pieces of a larger whole.
I cleaned up the drag-and-drop model and refined the user experience for showing where users could place their blocks. I also created additional blocks, based on what was available in other products and what our users would want available to them.
I designed the preview experience for the page in three sizes: desktop, tablet, and mobile. The bulk of the work went into the blocks themselves: refining the design of existing blocks, creating the design of new blocks, figuring out their different styles, and then coming up with what the blocks looked like responsively, and at what breakpoints they would change.
As the engineers began building the feature, I worked closely with them to make sure our designs were clear, and that I could answer any questions that came up. As we neared the GA deadline, we had to prioritize which features to save for future iterations and which to build for the best GA experience. I worked with the product manager to make these decisions, ensuring that we were delivering the best possible product to our users.
06. Final
Overall, we spent seven months working on this feature, with a joint effort in our product triad – PM, Design, and Engineering. Two years later, I can proudly say that our design increased monthly viewership by over 400% and new page creation by 350%. This is certainly an achievement to be proud of!
What would I have done differently? This design effort was executed under true “start-up” conditions. We had to release quickly and didn’t have direct access to customers. As a result, the majority of the design was based purely on design heuristics, intuition, and competitive research. I wish we could have built in more time for usability testing, as we found areas for improvement once we conducted them. This taught me a valuable lesson: design must fiercely advocate for our users. Due to the need to release quickly and move on to other projects, some parts of the design that I wanted to see implemented were cut. These cuts could have improved both the usability and adoption of the feature. As I moved on to other projects, I learned how to negotiate what would meet our GA bar, while still prioritizing our users.
