We had designed an eCommerce experience that was reliably lifting conversion rates by up to 5x over traditional eCommerce sites and getting positive feedback from customers and end users. Now we needed to create a product that would allow us to scale that success. This case study shows the process we followed to design the web-based page builder that would be our SaaS product.
On a small team, everyone has to wear many hats. My role was a combination of design and customer development. It was my job to meet with our customers, understand their needs and goals, and translate that into a saleable and useful product. As a product owner, I helped define product strategy, conducted user research and testing, and helped defined product requirements. As a designer, I produced a site map and user flows, detailed wireframes, a style guide, and high-fidelity design comps. My team comprised a technical PM and three developers.
The message from our customers was clear: they needed to easily and quickly create custom eCommerce landing pages without having to rely their platform team.
If we could build a self-service tool for creating landing pages, then the time, effort, and cost needed to launch a page would be significantly reduced.
So that we’d have a clear picture of what success looks like, we defined objectives and key results for our product.
To better understand our customers and how they worked within their organizations, we spoke with them and mapped out their org. structure. This process helped us define our user types and their respective goals.
Our primary user type was the Digital Marketing Manager. This person was responsible for configuring their landing page and managing their campaign.
To define tasks, we looked at the output of the product (a fully populated and configured page) and listed out all the steps required to get there:
Each of these tasks have subtasks, which we summarized and described as user stories, and then translated into features and requirements. We listed everything in a Google spreadsheet.
We started concepting by sketching various user flows, screens, UI elements and interactions that could support each story.
From rough sketches and ideas, we went into simple wireframes and built some basic elements of the product that we could use and test internally. For example, we built a very basic interface for importing product data into our database that we used internally before rolling out this feature to our customers.
Before working on detailed designs, I mapped out the various pages of the app and showed how they’d work together to enable the user to get things done.
In the sitemap below, you can see the top-level navigation (Pages, Analytics, Template, and Settings) and the three flows that make up the page builder feature (import, tag, and arrange content).
Going through this exercise made us think about the product as a system of interconnected modules. From this perspective we streamlined our approach to content management and reached consensus on which features to focus on first.
With a sitemap in place, I created wireframes for the various screens and interactions that made up the app. I designed interfaces that supported major tasks like selecting a page template, importing content, tagging content, and arraigning content. I also visualized and described interactions that would provide feedback to users as they completed tasks.
Creating wireframes helped me define which elements would would make up the various interfaces. From this list of UI elements, I created symbols in Sketch and applied a basic set of shared styles to get me started.
To come up with the visual design, I referenced two things. 1) Our product objectives: We knew we wanted this app to feel approachable and trustworthy. 2) Our logo and visual identity, which I had already designed. With these two inputs, I played around with different styles until I came up with something I liked.
Ultimately I put together a style guide (a page with shared styles) and component library (a bunch of symbols) which I used to design the rest of the screens in high-fidelity.
Using our component library, I composed several of the most important screens in high-fidelity. These visuals allowed us to see areas for improvement that weren’t obvious with wireframes. The designs went through several iterations and refinements before going into production.
In addition to producing static comps, I experimented with different interactions. Similar to the process of creating high-fi comps, by going to this level of fidelity with interactions, I started see ways to improve things. One improvement that came out of this experimentation was the ability to manipulate content directly, using over controls, versus having to click on a piece of content and then access controls from a side panel.
Copyright © 2018