Case Study — Technical
Domain Search
Topic.
How should we show results for domain search?
Role.
Product Designer responsible for end-to-end design process. Core team included 1 Product Manager, 3 Front-end, 2 Back-end Engineers, and 1 Support Specialist.
Business Goals
For more than a decade, Squarespace had been the premier choice for building beautiful websites. We wanted to expand our product line and offer a new entry point for customers to get started with Squarespace, while also giving customers the ability to manage their online presence in one place.
User Goals
We wanted to make domains exciting. Understanding how domains work is a bit like doing your taxes; there is a lot of jargon, not much innovation, and some necessary steps you can’t get around. We thought that if we could “make domains fun”, it would really set us apart from our big name competitors. We wanted our potential customer to be out with friends having a conversation about a ridiculous business idea, and be able to search and purchase that domain from us on the spot.
While we were eager to see what part of domain management we could simplify for our majority user, we also knew that there were a significant amount of technical people out there that we wouldn’t want to insult with our hand-holding.
An early mobile-first concept. Domains had to be search and purchasable on the go.
Research Goals
We conducted internal interviews to gauge the average persons understanding of domain search and management. We found that there was very little understanding of the difference between a website and a domain; very few customers who had purchased multiple domains could explain the process; there was almost no trust in a non-common TLD; no-one found suggestions helpful or relevant; and having a .com was synonymous with “being on the internet”.
What would success look like?
If customers purchased a domain from us to go with their website, rather than using one of our generic URLs, this would be success. If customers began purchasing domains as a starting point, this would mean that we had succeeded in opening up a new channel and would have a whole new cohort to learn from.
We also wanted customers to buy non-generic TLDs. These were fun, more widely available and also came with a higher price tag, By educating visitors about these new options we hypothesized that even if a customer knew exactly what they wanted the first time, they would remember Squarespace for the next time.
Process
I remember designing up a visual mock to see how the search field might look and how many search results we could fit on a page, and then an engineer asked me “OK, but how are they ordered?”. I was thinking “Wait, is that something I can decide?”. No-one had considered this yet, we were a very light team, so I simply started writing up what made sense to me.
My first documentation of search logic
We knew a few things from our goals:
1. Don’t be too sales-y with recommendations or suggestions
2. Prioritize exact match and common TLDs
3. Promote 300+ unique TLDs
4. Return results fast
I started writing very manual logic. If the users types a string, always show the .com first. This was based on the observed understanding that .com=internet. Then we force ranked the ten (10) common TLDs and agreed to return them in a static order.
Below that static list, it was a discovery zone. The fun part came when my PM and I went through all 300 TLDs and assigned them to categories that we would use to filter the rest of our offering. This would also help us speed things up as, as we wouldn’t need to serve all 300 options at a time. Logic-wise we specified things like; If a user types a string that is also a TLD, raise that into the 2nd position; If the user types a location variant, look for a ccTLD match.
We used a demo site to test animation and speed. Once the user started typing, we would start the query and populate results while running the availability check.
A couple items that we went back and forth on and ultimately decided against were:
1. Should we even show unavailable results (sometimes a user would see a whole page of unavailables).
2. Should we do an “I’m feeling lucky” button
In deciding how to order the result, we weren’t doing anything smart yet to determine relevance, so our remaining levels were by alpha, price or random. In design, I added toggles for each of these and decided to default “random”, as this seemed like it would cast the widest net, while showing variation in pricing.
This process was a super collaboration with the whole team and moved so smoothly. It’s incredible that we still use the same logic today.
Why is this project important to me?
This project was such a joy to me, and I still reflect on it as one our my favorite times at Squarespace. I was able to work on an end-to-end product in a truly collaborative style, before we even had anything written down like “process”. As a team, Domains was the first hacked together org team, so we laid foundations for how other teams would be structured.
A sizzle gif created for launch comms
After Squarespace Domains launched, our Biz Dev team travelled to an ICANN conference and began receiving feedback that we were now the ones to watch for innovation. Following on from that, the domains product was the star of our 2016 Superbowl campaign and remains the only non-website product to have a full campaign dedicated to it.
Domain search today 2020