Case Study — Visual
Account Dashboard
Topic.
How might we give customers a place to see all their subscriptions in one place?
Role.
Product Designer responsible for the end-to-end design process. Core team included 1 Product Manager, 1 Front-end, 3 Back-end Engineers and 1 Support Specialist.
Business Goals
As the company expanded its multi-product offering, we needed to create a single space where customers could see all the subscriptions they were managing in one place. There was a hypothesis from support team leadership that customers were failing to renew their subscriptions because it was not obvious in the UI where to take billing actions. The new design would need to lay a framework to support multi-product users, as well as give a general health check of their subscription information.
User Goals
We wanted to give customers with multiple sites or domains a way of seeing them all in once place, and allow them to take action on any subscription from there. For any customer who only manage one subscription, we should use the space to educate on other product offerings and give them the opportunity to start something new from this new space.
Research Goals
We needed to learn more about our users. To create a content model for multi-product users, we first needed to know the current make up of our users, such as; the average number of sites per users; how they handled renewals; how frequently they logged into Squarespace. From this we would figure out what kind of user we would be optimizing for.
We often think of our average customer as someone who is running a business on Squarespace, but at the same time lives a passionate side hustle. Their dashboard would look something like this. In reality, 90% of our customers have one website, with Circle members averaging around 5-6. What would success look like?
Feedback from our multi-product customers was the most valuable success metric to us here. We anticipated that they would enjoy the update in general, but we were eager to learn how they would come to use the area, and what kind of information was valuable over time for various cohorts. We really felt that this was an optimization that had to be made to grow the platform.
Process
This project came to me as an idea from the CEO. There was no team dedicated to subscription or account management at the time, so I ended up having to scope the project out and get buy in from teams for engineering resources.
Defining the goal of this space was the hardest part. Some of my team saw it as navigation, a train station to get from site to site. Others saw it as a machine learning dream dashboard that would be covered in graphs and analytics to offer daily recommendations.
Designers gather to sketch out “What should be on a dashboard?”. You can see that depending on where that designer typical spends their time, their cards lean towards either analytics, up-sells or support info. The way I pitched it was; Yes, at the very least this space will function as navigation, but the value for user would be getting an overall pulse on the health of their subscriptions. We would eventually be able to get to a place where we make suggestions for you or your business based on what we know about you, to ensure that this dashboard is somewhere they would want to visit daily.
I quickly got an engineer on board and we worked in code to validate some our peer feedback. Would the card components I was designing look like something that would navigate me to a new page, or did they look like something I could click for more information?
At the same time, the design team was working on a new design system, which would be a dramatic shift from where we were. The design I was doing had to be future thinking in its implementation to loop back into this new system, but also not corner us if the overall direction moved. It was endless iterations of corner-radii, box shadows, white or grey backgrounds, input styles, animation guides … everything. This project was the first implementation of the newer design system you see in Squarespace today.
The card component was complex. We had to determine how the user wanted to interact with different touch regions. Would the expect clicking on the card would take them to their site, or to a detail page? Would we be getting in the way of users by adding more data?
Visual explorations of card styles and elevation. We would go back and forth a lot about whether we were a rounded corners company or not. 
The Dashboard also had to be integrated with our mobile apps so that users could navigate between sites. We punted on domain management in the app, meaning we didn’t require a tab structure. Results
The majority (~90%) of our users still only have one website or one domain, and those that have multiple use the dashboard as a way to navigate between sites or simply manage their account details. Due to our interaction model, single product users would rarely encounter the dashboard, meaning that they were unlikely to go there to start something new. We found that only 20% of users with paid sites visited the dashboard. We decided to invest more in that navigation mentality and not try to bring more features into the dashboard, but instead operate more as a launch pad into other areas of the platform.
Why is this project important to me?
This project defined the styles that we would use throughout our new design system and also set an engineering precedent for how styled components could be rolled out cross-platform. Multiple teams were spun up from this initiative including one dedicated to the dashboard and all things Accounts.
Account Dashboard 2020