Summary
Over the course of 7 months, I, a second product designer, and a team of engineers took a rudderless beta feature, gave it a goal to build towards for a GA release, and built it. I conducted adjacent product research to help inform the direction, designed the northstar vision, and then designed and supported the build of the GA MVP, including technical specs for the engineering team to follow. As a result of our design, we increased monthly viewership of created Smartpages by over 400% and new page creation by 350%. Smartpages become a cornerstone of the Highspot product, empowering customers to easily create a compelling, informative layer of guided experiences and native content.
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
03. Discovery
I was told that we wanted to refine the Smartpages feature enough that it was ready to release to GA. We were a startup with a product department of around 40 people, and we were short on Product Managers. As the design lead, I took it upon myself to help drive the project forward. My first step was conducting competitive research. I wanted to see what other products were doing and how we might emulate best practices from them. We had already identified 7 main pain points from discussions with our current users:
- There was no way to preview how the page looked on other device sizes.
- There were two distinct ways of customizing a block you drag to the stage (right sidebar or full-screen html editor) but the difference was not clear to users.
- There wasn’t a good way to group items horizontally to allow them to stay together as a page was viewed on narrower viewports.
- There was no concept of a “theme” which could help keep a page’s design more consistent and clean, offering a better user experience for both the creator and the consumer of the page.
- There were no pre-made templates that make creating a Smartpage faster and easier for users that didn’t want to create something from scratch.
- The block options for creating Smartpages were limited and tended to lean heavily on custom blocks, which could lead to responsive problems and difficulty for users that didn’t know how to code.
- If a user created a specially-styled block they would like to reuse, they had no way to copy it for use on that same Smartpage or other Smartpages.
In my view, the idea of Smartpages was more geared toward web builders (creating a single page of beautiful content) rather than something like a document, so I researched other mainstream web builders at the time (Wix, Weebly, and Squarespace). With the pain points already outlined, I focused on the main topics of responsive design, previewing responsive design, full bleed images, building pages, page-level “themes,” and what blocks are available to use. I created a research document that presented the information that I had discovered. Using that research document, I created our goal for the Smartpages feature: to create an experience that allowed our users to create beautiful content easily and didn’t require them to know coding to be able to do it.
04. The Research
My research was collected into a summary document that we used throughout the process to help us decide what we should be focusing on for feature parity.
05. The Process
Following the research, I was both daunted and excited at the idea of working on the Smartpages feature, which was complex enough that it could 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, and making those blocks easy to modify (while still maintaining defaults that allowed users to have a good looking page without modifications). We also needed to be able to make it clear to users where they could drag and drop their blocks on the stage, and show the underlying structure of the page.
The clock was ticking, and I didn’t want to be a blocker for the engineering team. My first step was to create a holistic northstar for what we wanted the Smartpages feature to be. It was important to have something that would help guide us, and show that all the individual pieces that needed improvement were pieces of a larger whole – but they needed to fit together to have a positive effect. I cleaned up the drag-and-drop model and refined the user experience for showing where users could place their blocks, trying to make the structure of the page clear in that process. The architecture of the page was based on a column model, which was at odds with the other products I had researched, which was row based. Unfortunately, it was too costly in Eng time to change from columns to rows, so our users needed to understand how the blocks would fit together, especially because if they got it wrong, the page’s blocks would reflow in a non-logical order.
I created additional blocks, basing them on what was available in other products and what our users would want available to them. Six blocks grew to eleven, and my designer and I worked closely together to design the properties pane that would allow our users to customize the blocks – coming up with a consistent system to improve ease of use. 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. I went through every single block and figured out their dimensions at the different breakpoints, detailing it in a spreadsheet that later went into the Jira tickets for the engineers.
As the engineers began building the feature, my designer and I worked closely with them to make sure our designs were clear, and that we were able to answer any questions that came up. As we neared our deadline for GA, we realized that we weren’t going to be able to hit it. Due to business priorities, the deadline wasn’t going to move, so I worked with the product manager to help define which features in our northstar would be saved for later iterations of this feature, and which would be built for the best GA experience.
06. Final
Overall, we spent 7 months working on this feature, and it was a joint effort between our product triad – PM, Design, and Engineering. Two years later, I can proudly say that as a result of our design, we increased monthly viewership by over 400% and new page creation by 350%. Certainly nothing to sneeze at!
What would I have done differently? This design effort was run under true “start-up” conditions – we had to release fast and we didn’t have direct access to customers. That meant that the majority of this design was based purely on design heuristics and intuition, plus the competitive research I did. I wished that we could have built in the time to do more usability testing, as once we did conduct them, we found some areas for improvement. And this led to a good lesson learned: design has to advocate fiercely for our users. Because we needed to release fast and move on to another project, parts of the design that I would have liked to see implemented ended up getting cut. Those cuts could have improved both the usability of the feature and the adoption of it as well. As I moved on to other projects, I learned how to negotiate what made our GA bar – on behalf of our users.
