The Challenge

Improve Swiftype’s user interface without modifying the functionality of its core features.

My Role

Conduct user research, sketch, mockup static interfaces, illustrate icons, and code the real thing.

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:

  1. Strengthen visual hierarchy and clarify navigation everywhere, including designing a new icon set that is extensible and legible at small sizes
  2. 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
  3. Find and implement a more appropriate interface font that can also be used as part of the Swiftype brand
  4. 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.

Fonts

One aspect of the existing design that handicapped our ability to create effective hierarchy was Swiftype’s ubiquitous use of the font National.

National, designed by Kris Sowersby, shown in Light, Book, Regular, and Medium.

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.

Old Swiftype dashboard, Nov 2015. text-transform: uppercase all the things!

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”.

Acumin Pro, shown in in Extra Light, Light, Regular and Medium. Designed by Robert Slimbach.

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.

Navigation

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.

Old Swiftype dashboard, Nov 2015. An example of poor visual hierarchy; the three sections share no clear connection. The active tab is also incredibly difficult to spot at a glance.
An early dashboard mockup which experimented with layering levels of navigation from left-to-right. Pros: beautiful hierarchy, logical connection between views; sidebar simplifies navigation and removes need for dropdowns. Cons: narrow leftmost sidebar relies too heavily on icons and has no room for labels; account name cannot be displayed persistently and settings link is relegated to the bottom left of the screen, which may be overlooked; shift may confuse and frustrate users who have grown accustomed to the existing interface.

After sketching, designing mockups, and iterating and polishing directly in the code, our final product looked like this:

swiftype-screenshot
  1. The top-level nav takes top-level prominence. “Engines” remains at the top but is enlarged and moved to the left, where users would expect to find the main navigation. Planned future dashboard expansions will appear beside it.
  2. The “Account” link and account switcher dropdown are consolidated into a single user menu, allowing users to manage account settings, switch between accounts, and log out.
  3. The active page is easily visible and does not require hovering.
  4. A persistent sidebar beneath a prominent label/quick switcher for the active engine both emphasizes the relationship between the two and makes navigating easier.
  5. A dark body and sidebar bring focus to the content of the dashboard, allowing the surrounding chrome to fade into the background.
  6. All-caps text has been eliminated almost everywhere. Text contrast has been increased to maintain a 4.5:1 contrast ratio, and all text sizes have been increased.
Below a certain width, the sidebar will condense to a top bar with dropdowns. This takes advantage of screen real estate when it is available, but provides a fallback for users with smaller screens. The appearance and positioning of the engine selector is identical in both scenarios, reinforcing that regardless of whether you see the top bar or the sidebar, the navigation is the same.
The navigation pattern for account settings is identical, with the addition of a “back to Engine” link in place of the engine selector.

Icons

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.

Original Swiftype nav icons, created by a former designer on the team. These icons were originally drawn at 48px for use on the marketing site, and were later scaled down to for use on the dashboard, making them fuzzy and difficult to read on non-retina displays.
Iteration 1: two-tone, 1px stroke icons, à la Dropbox or Finder. A little too delicate. Icons such as result rankings and analytics modeled after the original, but do not hold up well at this size. It also provoked the question: is an atom really the best representation for analytics?
Iteration 2: single color, larger, rounded icons. A little too chunky and childish for Swiftype’s voice. The analytics icon has been changed from an atom to a line graph. Are those synonyms or bacon?
My final, two-tone icons. Large areas of white, such as in the analytics icon, have been broken up to create a more distinctive silhouette and to make the icons feel lighter. The addition of a second shade also helps to decrease visual weightiness.

Dashboard Home

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.

Old Swiftype dashboard, Nov 2015.

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.

swiftype-home-screenshot
  1. Enlarged and expanded cards now fill the available width, significantly increasing tap/click targets.
  2. Percent change up/down from the previous week was added to the analytics for searches and autocompletes, providing context to numbers that otherwise have little meaning. Clicking this half of the card will take users directly to the relevant analytics section without the need for an extra click.
  3. Archived engines are now filtered out and moved to the bottom of the list, rather than being displayed inline.
  4. Account activity is moved from below the engines to the top right of the page, underneath Swiftype announcements, visible sans scrolling.

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).

Illustrations for empty states.

Results

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.

That's it!

Thanks for reading. Some additional work from Swiftype can be found on my miscellaneous page, or you can read through more case studies below.