Step 1: Overall Formatting and Styling

When you first open the search experience and click around, what is your impression of the site? As the reviewer, you’ll want to check that the overall branding and feel of the site is consistent, clean, and aligned with the client’s site. This means that the frontend components work how they’re expected to and all fit together well visually. As such, this tab is part of the user interface QA.

Here are several items to check for in terms of overall formatting and styling:

Branding Matches Client’s Site

Fonts, colors, and CTA buttons should allmatch the client’s site. Users shouldn’t feel like they went to a different site to conduct their search. The admin may have a reason for deviating from the client site’s typical colors or fonts, but always flag it if you notice a discrepancy. There should also be sufficient contrast between all colors used for accessibility. Check out the Hitchhikers unit on Updating Standard Branding Elements for a refresher.

Consistent CTA Button Styling

It is possible that the Admin applied styling for the more obvious CTAs on verticals such as locations or products, but did not apply the styling to CTAs on cards such as FAQs. Unless the Admin applied different styling across verticals intentionally, it is generally best practice to maintain consistency of styling.

The Admin may not be able to replicate existing CTAs exactly, or there may be several different button styles, but it is generally best practice to mirror the client’s CTA styling as closely as possible. This would include things like:

1. Text, background, and border colors
2. Border radius
3. Hover behavior

Check out the CTA styling example in the Custom CTA Code Examples reference doc.

Facets/Frontend Sorting (if applicable)

Check out the Hitchhikers modules on facets, filters , and sorting to refresh your memory. A few considerations for evaluating facets/filters/sorting:

1. If facets, static filters, and/or frontend sorting have been enabled for any vertical, do a general check to make sure they are functional.
2. If facets are enabled for any given field, it is suggested to also add an inferred Filter on that same field, as this allows the facet to be automatically checked when the user searches one of the values. You can check this on the frontend by seeing if applied filters appear when a facet is applied. You can also check this in the backend config.
3. If a facet has a lot of options to choose from, consider making it searchable.
4. If enabled, check to see if they collapse correctly on mobile (a button to choose sorting/filters shows up instead). You can quickly change the size of your window to ensure they collapse.
5. If facets are not enabled, check if there are fields we can suggest adding facets for. Generally speaking, if there is any sort of categorization for a vertical, such as product category or location type, it is suggested to enable that as a facet and inferred filter.

Appropriate Universal Limits

Universal limits (check out the Shared Vertical Settings reference docs) set the maximum number of entities that show up on universal search for each vertical. You will need to run searches that display results for each vertical, with the number of results equal to or greater than the universal limit for each vertical. An easy way to do this is to run a search for each entity type included in the experience since most verticals will include an inferred filter on builtin.entityType.

A few considerations when evaluating universal limits:

1. Each vertical should have a reasonable limit to ensure it doesn’t take up the whole page and hide the other verticals below it. This is particularly a concern on mobile.
2. Any vertical using a grid layout should have a vertical limit that corresponds with the number of columns. For example, a three column grid could have a vertical limit of 6 or 9, but using a vertical limit of 4 or 5 would look awkward with the three columns.

Page / Card Layouts

The page and card layouts chosen for each vertical should clearly and effectively present the data we want to show. Does the choice of layout make sense for:

1. Page layout - standard, map, or grid layout for universal search and each vertical
2. Card layout - use the appropriate built-in card or create a custom card

Browser Testing QA: Mobile Display and Behavior

It is up to the Admin to test the experience across multiple browsers on various devices including mobile, but it is important to double check that the experience works well on mobile. As part of the review for the overall formatting and styling of the experience, you could change the size of your browser window to imitate a tablet or mobile device or just open the staging link on a mobile device. Then check the display and behavior of the site, similar to what you did above, including:

1. Page and card layouts look appropriate.
2. Fonts, colors, and CTA button styling resembles the client’s mobile site and is consistent across the experience.
3. Behavior of buttons, prompts, vertical map, etc are expected.
4. Sorts and filters collapse correctly.
5. Universal limits are appropriate and users do not have to scroll far on universal search to see results from the next vertical.