Swiftype is a service that lets anyone easily add search to their app or website. It’s used by companies like Twitch, Shopify, Techcrunch, and Designer News, and gives users the power to tailor their search experience, from filters and faceting to result rankings and appearance. One of the first projects I took on at Swiftype was to make visual and experience improvements across the dashboard.
Research and Goals
Speaking with Swiftype’s customer support team, we identified questions that often came up for new users, isolating pain points and assembling a timeline for what users experience as they progress through the app. Where were users dropping off? Why? What elements of the dashboard were confusing or unclear? Why? Were there any patterns that seemed to cause a drop in engagement? Why?
From this research, we established that navigation was holistically confusing to new users, and that users had difficulty understanding how different views within the dashboard were related to each other. In order to solve these problems, we decided to redesign the dashboard experience by laying out the following goals:
- Strengthen visual hierarchy and clarify navigation everywhere, including designing a new icon set that is extensible and legible at small sizes
- Reduce and eliminate inconsistencies by establishing conventions for how pages should be laid out, how buttons should be colored and positioned depending on their purpose, and how copy should be written
- Find and implement a more appropriate interface font that can also be used as part of the Swiftype brand
- Clean up and organize the CSS, establishing and enforcing naming rules in order to help maintain consistency, reduce technical debt, and simplify future changes
Due to organizational limitations, all of these changes had to be made solely in the front-end, without touching the core functionality of the app. This limited some of our more aspirational redesigns (but don’t worry—I’ll share those at the end!) Below are the solutions we arrived at for the points above, along with how we transformed the dashboard homepage using user data as a guide for design decisions.
One aspect of the existing design that handicapped our ability to create effective hierarchy was Swiftype’s ubiquitous use of the font National.
National is a beautiful display font that shines in large, light weights, but doesn’t hold up as well in an interface. The jump between Regular and Medium weights is too drastic, and text set in National appears two to three points smaller than other fonts set at the same size. To compensate for these quirks and a lack of wide or semicondensed alternates, previous designers at Swiftype had often set text in all caps. All-caps text works well in small doses, but can cause readability issues if overused, since there are no ascenders or descenders to aid in recognizing the silhouette of a word. In addition, text typed in all caps presents accessibility problems for screen readers, which will often read each. letter. one. at. a. time. Not to mention, all caps just feels shouty.
The design team experimented with several interface fonts, trying to isolate a typeface that could remain legible and useful in a variety of contexts, held character (but not too much character), and wasn’t overused by other brands. Among the contenders were Avenir Next (too playful), Proxima Nova (overused), Whitney (better suited for print signage, not digital displays), and Fakt Pro (a lovely font, actually, and one I could have seen us going with). Our final choice was the humble and utilitarian Acumin Pro, an Adobe neo-grotesque sans-serif “intended for a balanced and rational quality”.
Sensible bold and semibold weights gave us fine-tuned control over type hierarchy; condensed and semi-condensed variants allowed us to make the best use of limited space. Not long after the dashboard redesign, we put Acumin to work across Swiftype’s marketing site as well.
Based on our user research findings, the design team sketched and mocked up dozens of layouts in an effort to answer the following questions for every user:
- Where am I?
- How do I get back to the view I just came from?
- How does this page relate contextually to the dashboard as a whole?
- If I need to find a page or a setting I’ve never seen before, can I do that on the first try?
Or, more accurately—we weren’t trying to answer these questions; we were aiming to make sure they never needed to be asked in the first place.
After sketching, designing mockups, and iterating and polishing directly in the code, our final product looked like this:
As part of the redesign, all nav icons were redrawn to increase legibility at small sizes and on non-retina screens. As with the font choice, these icons went through several iterations in an effort to accurately convey meaning and maintain continuity with the existing voice/metaphors, but evolve in a logical direction.
The original dashboard homepage was essentially a glorified engine selector. It would display all your engines in a three-column grid of cards that included two small lines about analytics. Our user data revealed that over 99% of users had four or fewer engines total—a three-column grid might work well for a dozen engines (an amount close to the number that Swiftype manages internally), but was not conducive for the majority of our user base, most of whom would not even fill one row.
One idea floated was removing this view entirely—why not redirect users to their most recently used engine, which they’ll probably want to access anyways? This would remove redundant information on the homepage, and cut out one step in a common workflow. However, without a proper “home”, there would no longer be a logical place to display an overview of all engine and account activity or show Swiftype announcements and alerts.
Due to the above concerns, we decided to keep the view but provide more useful information and optimize for four or fewer engines. Along with learning about 99% of users having four or fewer engines, our logged events indicated that the links in the sidebar—the ones labeled Account, Help & Support, and Resources—were almost never clicked. Most of them were duplicates: account settings, support, and documentation can all be accessed from the header regardless of what page you are on. This left two unrepeated links in this sidebar—Search Concepts and Case Studies—which over a period of several months were clicked less than a dozen times by thousands of active customers. In other words, they were safe to scrap from a high-value position in the dashboard’s most trafficked view. In their place, we relocated account activity (now always present above the fold) and a dedicated spot for Swiftype product announcements.
The dashboard home resides inside a dark container rather than the light one that is found everywhere else in the dashboard, emphasizing a relationship “above” or “behind” the rest of the dashboard. Users with more than ten engines will see a condensed list view. This page was crafted from the ground up as the first fully-responsive Swiftype dashboard view, allowing users to easily preview their engines’ analytics even when the rest of the app is not yet mobile-friendly.
Cleaning Up CSS, Creating Conventions
Internally, over 96% of the CSS was refactored and reorganized. We eliminated a massive, single stylesheet, breaking everything into partials containing modular, reusable components and eliminating overspecificity. In total, over 8,000 lines of CSS were removed or rewritten.
Conventions were established for interface copy (e.g. “Capitalize All Words In Buttons”, “Use Title Case for Titles”, and “Use sentence case and a period for descriptions.”) and naming (e.g. if we call them “Weights”, let’s do that everywhere, and not refer to “Search Relevance Functions” in some places and “Weights” in others).
We also established conventions for things such as button color (blue: primary action, white: secondary action, green: plan-related actions, red: dangerous actions) and empty states (I created over a dozen illustrations, in the process consolidating several different layouts into one reusable template).
All of the changes our team made were received positively from users—there were zero complaints (!), and we actually received several complimentary emails from customers, as well as kind notes during our scheduled customer feedback survey. A clean codebase will simplify future improvements and expansions to the dashboard.
I was super happy with how easy the initial site integration and launch was, and service has been on point. Thanks guys.
Love having this level of detailed control over search results, laid out in a very user friendly way.
Although our changes were well received, the app is still far from perfect. You can rearrange the furniture to make a house flow better, but sometimes what you really need is to knock down some walls and fill the cracks in the foundation. Unfortunately for now, changes of that scope go beyond Swiftype’s engineering bandwidth.
In an ideal world, customizations like result ranking, weights, and styling would not be scattered across half a dozen different views, as they are currently. They would be condensed into a single view that allows users to edit and preview their search simultaneously, concept being: the interface you use to make changes to your search is the exact same one that actually displays your search. The best navigation is, perhaps, no navigation at all.