Kevin Garcia

Refining the SeafoodWatch search experience

The initial SeafoodWatch search app was a success, but we were noticing a few usability issues with the search experience. This was an exploration that led to refinements to the search experience.

SeafoodWatch landing page

Exploring the problem

The project manager further explained that users find the search being anchored to the top of the recommendation after a seafood has been selected confusing, and requested we change the way the page offers the user to ‘search again’.

Existing behavior: Landing on the group overview, group of recommendations, or the final recommendation, the page automatically scrolls the user down so that only part of the page is visible.

This is problematic, because on a slow browser or connection, this results in the page automatically scrolling the user down to a waypoint after the user has begun orienting themselves in the page. This disrupts the user as they are starting to explore the page.

Furthermore, when browsing with fast connections/browsers, the scroll happens almost instantly, resulting in the user not having a context cue that they can scroll up to return to search.

Almost as soon as you land, the seafood watch app scrolled you past the title

Additionally, this creates a large area of wasted space at the top that we are either scrolling past, or that contains redundant information. Expecting the user to know, without any context cues, that they can scroll back up in order to get back to search can also cause confusion.

illustration of wasted and redundant space

Further analysis

The Seafood Watch Recommendation Search App is masked within the structure of the Seafood Watch website, and I think this is where some of the confusion and redundancy starts to set in. The app itself, has a consistent experience.

Wireframes revealing app structure

When we look at the app in context with the website, we start seeing both redundancies and inconsistencies.

The user flow starts at “Seafood Recommendations”, “Seafood Search”, or “Sushi”, (depending on where you start your search) to “Tuna Overview” (in the instance where there is a group with a description)—or “Tuna Recommendations” (In the instance where there isn’t), then “Tuna, Albacore”

This is repeated again in the title either above, to the right, or below the picture of the fish, with a slightly different variation. “Tuna”, “Tuna / All Recommendations for Tuna” and “Tuna, Albacore”

Seafood Watch App pages illustrating user flow

Removing the search component and the scrolling behavior from the top of the app, this issue becomes even more visible because of the proximity of the headlines to each other.

Removing search highlights redundancy issues

A possible solution is to brand the entire experience “Recommendation Search” - Which then allows it to stay consistent to the Seafood watch branding, and allowing the app give the user context cues for where they are. This highlights a few new problems.

Removing search highlights redundancy issues

The Group overview page has no information beyond a description, and a call to action to go view the recommendations. In the instances where the user lands on a group page, they, have to actively click to get to the Recommendations page that lists them all and allows you to drill down to a single recommendation. Furthermore, having removed the search bar from the top, there is no clear way to navigate within the app itself. You can easily go from Group->Recommendations->Individual recommendation, but there is no obvious path to backtrack or search again, beyond going back up to primary navigation.

Exploring solutions

Moving search to the bottom

This is the simplest solution the requires the least ammount of refactoring. It also leaves the current experience mostly intact.

Moving search to bottom has its own challenges
This is the least disruptive option in terms of user experience and technology refactoring. By moving the search to the bottom, we also “unbury it” from the scrolling behavior, and it gives our users the ability to search again if the screen they landed on is the wrong one.
None of the other consistency issues are addressed. Having the search at the bottom disrupts the existing experience, and users may abandon the page before they reach it.

Moving search to the sidebar

This would require significant refactoring of the entire experience, primarily because the only place where there is a sidebar that could have an integrated search is in the multple recommendation overview page. Both the Group Overview, and the Individual Recommendation are designed as a single column display. This approach allows us to address a few other issues.

Moving search to sidebar is preferable
This approach allows us to remove the “group” page alltogether, and combine it into the recommendation search. When available, the Group information should be presented together with the recommendations in the recommendation search. Finally, we can bring the sidebar back into the individual reccomendation page, giving us a space to search again, or return to the recommendation results for that type of fish. This approach fixes a lot of the consistency issues we’ve explored, and also allows us to simplify and streamline the search experience.
This is a broader fix that requires more resources than what may be available short term.

Refining the experience

Redesigning the “Group” layout allows us to leverage the existing information and populate the group recommendations, while also allowing us to surface more information to the “Refine your search” experience.

Refining the group search experience

Finally, the individiual result layout also allows us to introduce a place to either return to the recommendation results, or to search again within the app.

Refined detail page