.gif)
so black + white
Solving colors isn't
I led the redesign of the Squarespace Colors management system, from the panel to canvas-level interactions.
Tools
↗ Figma
↗ Amplitude
↗ Zendesk
↗ Principle
Skills
↗ User Testing / Synthesis
↗ Rapid Prototyping
↗ Cross-Team Collaboration
↗ Data Analysis
Deliverable
An overhauled Fonts panel experience with new hover states & microinteractions to clarify how to successfully navigate and configure typographic settings.
The Ask
Understand how users work with the fonts panel, identify areas to optimize, and redesign the end-to-end experience of managing fonts on a site.
The Ask
Understand how users are struggling with the current Color management experience and translate these insights into usability improvements.
Deliverable
An overhauled Colors panel experience, new canvas-level interactions, and phased recommendations for future improvements.
9%
Increase in designer palette selections
56%
Increase in palette customization
Colors Diary Study
In late 2020, the Styling team partnered with our amazing UX research partners to run an in-depth diary study. We were able to observe users who were just starting out their website trials.
We noticed the following trends about user behavior.
1. Users did not know how to find key palette features
When palette options are collapsed into a modal, it’s extremely difficult to discover them.
"Oh I thought that [dropdown] was just a label. I didn't know I could click to see more options."
2. Users don’t consistently understand section themes.
Users have divergent ideas of what a theme is and how settings in the theme editor impact their site.
"So this is where I set the theme for my site, right? Can I drag it onto the screen?"
3. Users expect to style elements by clicking them directly.
Users’ default mode of styling is to approach their canvas like a Canva page - click to edit.
"I want to just click on this and change the color. Why can't I do that?"
Problem #1: Palette Inaccessibility
I explored a few different solutions to increase the accessibility of our palette editor.
The purpose of these early explorations was to think of an ideal solution, without fixating too heavily on system rules. These explorations were quite adventurous and allowed me to problem-solve without creative restraints. I took inspiration from design tools like Coolors which many of our users use to generate palettes.
Old palette
Surface functionality
Our palette is actually a pretty powerful and useful feature, but its functionality was buried in a popover. We wanted to surface these valuable palette configuration settings.
Create a consistent system
I wanted to align the Colors panel architecture with the Fonts panel, which nests the style catalog one panel deeper into the panel and surfaces the settings of the active selection.
Refinement
After discussions with my PM, we decided to scope down this work to what was accomplishable within two sprints (4 weeks). I partnered with another designer on my team (the talented Peter Colón), who took my initial explorations and simplified them with the help of existing design system components.
I worked with engineers to demo the prototype behavior and align the team on expected behavior.
The 🍒 on top
We partnered with a web designer on our team (the talented David Kirschberg), who designed a seamless transition between the palette and the palette editor. The result was a beautiful example of motion design which isn't just aesthetically delightful, but functionally meaningful. The motion of the palette card into the individual palette editor swatches clarifies the relationship between the two panels.
I am using it now with a client and appreciate the more detailed line up of the palette colors. Certainly helpful to seamlessly edit a theme color for a background while on a page.
- Squarespace Pro User
Results
We ran an A/B test over a three week period to measure the impact of the new panel experience on key metrics, such as palette editing. The redesign overall netted a positive outcome compared to the control!
Test Summary
In the treatment group (redesign), users had greater engagement with colors. There was a 56% increase in users interacting with the custom color palette and a 9% increase in users interacting with the designer color palette options.
Conclusion
This was a very fun project to work on-- though it was just the first step in a huge opportunity area for expanding and optimizing our colors system.
Problem #2: Users want to edit colors directly
The second problem that we noted was that users wanted to edit their colors directly but were not able to. The only way to edit their site was to dive deep into the colors panel, select a color theme, and find the component they wanted to edit in a huge list of color tweaks.
Plus, even if they did find the tweak you were looking for, they'd be changing not just one instance, but every instance of this element within this color theme.
Editing the color of a site element
Why can't I just click this button and change its color? I hate having
to go into a million panels to change simple things.
— Theme across multiple user tests —
A tentative solution
I collaborated on this workstream with Pete, who proposed a "universal RTE" solution-- a way to access your colors anywhere on the page by just clicking on the element and triggering an RTE.
I modified an existing design platform component, spec'ing out how the RTE component would flex across a few different parts of our system.
Easier said than done!
Though it sounds simple, this workstream ended up being quite complicated! There were a few different factors to take into account here.
Technical constraints
We needed to tackle this work a single block at a time because each block is technically unique.
Design system constraints
We needed to work closely with the Design System team due to deviation from core components.
Legacy system constraints
We needed to do some cleanup work to our system empty state logic to make RTE possible.
1. Implementing a local RTE required a huge technical lift
Our system was never built to accommodate local edits. It's made up of 20+ blocks that are each uniquely constructed. In order to make a universal RTE possible, a huge technical lift was necessary to make previously global edits locally accessible block-by-block.
Part of my job was to scope out the work necessitated by each block and onboard engineers into the work.
I prioritized the blocks by system usage and phased out work depending on priority.
> Text
> Button
> Image
> Form
> Newsletter
> Summary
2. The RTE component was not constructed for our use case.
We needed to work closely with the Design System team to ensure that the changes we were making to the RTE component were compliant with system standards.
3. Our system is old + contains a lot of empty state inconsistencies
In order for the RTE to be foolproof, we needed text fields to be clearly accessible to users, even when they were empty. I worked with our amazing content stategist, Erika Templeton, to create a new logic for our empty states that could ensure that the RTE was always triggerable.
