Digital Search Case Study
Introduction

This case study explores the current state of digital search and presents possible solutions to problems people face. This personal design challenge was something that I wanted to take on after listening to collegues complain about their current experiences with search.

  • Project Duration: ~4/5 Weeks
  • Interaction & UI/UX Design
  • Team: One Member
  • Role: Primary Researcher & UI Designer
  • Tools: Adobe Illustrator, Adobe Photoshop, Sketch, Invision Studio
Background

People rely on search engines for basic tasks such as finding directions; as well as use them to assist in more complex tasks such as exploring a new neighborhood or discovering new information. After using a product for so long, user have developed habits that allow them to best navigate using these search engines. This case study explores digital search and what work arounds could be implement to improve a process that has been in effect for decades.

The Challenge

The scope of this design challenge is a bit different than a standard “redesign” or ideating a solution from a new problem space; instead I am challenged with taking a system that has already been perfected throughout the years and understand what design changes could be made to make it a better experience.



After some quick brainstorming and questioning, I thought up the following HMW questions to guide my thoughts throughout the design process.

  • How might we help users find relevant search results
  • How might we help users retain relevant info from search queries
  • How might we help users feel more accomplished with their search process
Research + Insights

The first task of my research was to understand how individuals utilized and interacted with search engines. To do this, I created a quick survey that I distributed to friends, and additionally asked 5 friends to participate in quick interviews. Because the problem area, digital searches, is so broad, I felt comfortable simply asking friends who I knew have used search engines before and did not need to create a criteria for who I wanted to interview. The goal from these research methods were to:

  • understand how users conducted search queries
  • how they responded to these search results
  • understand the pain points within their user journey as well as find design opportunities

After conducting the interviews, I placed the observations onto post-it notes and created an affinity diagram. This allowed me to visually identify commonalities between each interviewees search processes.

From the affinity diagram, I deduced 4 main insights about user interactions with digital search.

  1. Users can feel overwhelmed by the large amounts of search results, but feel obligated to sift through them.
  2. Because of a fear of missing out or losing information, users tend to open lots of search results and are afraid of closing the tabs.
  3. Users bookmark results that feel relevant, but often have too many bookmarked pages.
  4. Users use a primary search engine such as Google which leads them to opening webpages on secondary search engines such as Yelp, Amazon, eBay etc.

From the interviews that I conducted, I identified two primary use cases:

  • Search For Action
    • this use case can be defined as users who have a quick search query in which they want to quickly find the answer to complete an action.
    • this includes one off questions like:
      • “When does Thai Noodle II close?”
    • After this search query, users can take an action such as:
      • navigation to the location
      • call the location
      • view the menu
    • this "search for action" was often repeated (like a week later)
  • Search for Exploration
    • this use case can be defined as users who have an extensive question that requires users to sift through multiple queries and open several pages to find a succinct answer.
    • these included searches that could not be simply answered in one sentence:
      • “What was Karl Marx’s philosophy”
        • primarily a search query for student users who were doing research
        • often opens lots of search results
        • bookmarks / leaving tabs open
      • “Cheap running shoes”
        • while this does seem like a straight forward search query, users often did “research” to find a product that was best for them — looking at articles, shopping sites, and stores

After identifying the use cases, I created personas and a storyboard that helped to address and empathize with the pain points that exist within each use case.

Finding Design Opportunities

Design Opportunity 1:

The current user flow makes the use case “searching for exploration” a very tedious task. It places the burden of remembering relevant webpages on the users. The current solutions to this are for users to either keep the tabs open indefinitely, or to bookmark the page. Additionally, having all the results listed on one page can leave users feeling overwhelmed; and because of their fear of missing out, they tend to open multiple results in different tabs all at once.

Design Opportunity 2:

This design opportunity specifically targets the pain points regarding the “search for action” use case. Currently, previous search results can be accessed when users start typing in the query and is stylized in purple. Similarly, search results that have. The issue with this is that users don’t have context about the previously searched page, and don’t know if the page was relevant or not.

Design Opportunity 3:

When looking at how users utilize bookmarks, it become apparent that bookmark organization is wholly tasked onto the user. Users often start off organized, but slowly degenerate: not because of laziness, but not sure how things should be organized. Additionally, the bookmarks page is oversaturated with results because people have a fear of missing out and are afraid that would rather save the webpage just in case. This results in a cluttered bookmarks page that is not revised particularly often.

Design Opportunity 4:

After inputting a search query into a primary search engine such as Google Search or Bing Search, users will click on a result that leads them to a “secondary search engine” such as Amazon on Yelp and continue to sift through results on that webpage. Additionally, sometimes they may back track to the main search results page after using this secondary search for a while. There doesn’t seem to be a designated solution for this type of search pathway as of now.

Ideating

With an understanding of where I can start making design changes, I started ideating and sketching possible solutions.

In terms of finding search results, I wanted to implement a way for users to quick screen search results for relevancy, and mark them in a way that they could easily revisit. The ideas that encompassed this goal were:

  • no centralized page showing a list of possible sites
  • shows search sites right away
  • tinder style swiping

The goals of this design solution was to:

  • condense search history into relevant past queries which allows users to quickly find past queries
  • creates an innate form of organization, but also allows users to implement their own system of organization if desired

Easy toggle between general search, and specified search

Mid-Fidelity Mock Ups + Prototyping

The new search mechanism emphasizes quick decision making (as a key observation from the interviews was that users tend to spend between 30 secs to 2 minutes deciding if the webpage is relevant to them). The quick result sifting is supplemented with a save page that allows users to review their saved results at a later time and determine the best/ most relevant results.

The new search mechanism explained:

  • swiping left or right
    • familiar gesture
  • a notification arises when a webpage is saved, users can quickly “star it” or add a note to it
  • this process is repeated until a sufficient amount of webpages are saved, and the user can review them

While testing the mid-fidelity prototypes, an interaction issue arose:

  • the swiping gesture is useful on tinder because decision can be made more quickly, but within web search users need to scroll the web page to determine its relevance
    • the swipe to save/discard motion is too similar to the swipe to scroll web page → confuses users

As a result, I ideated different potential save interactions based on other apps that I have used and made prototypes to see how well users interacted with them.


Mechanism 2: Button-Press

Mechanism 3: Tab-Drag

Mechanism 4: Side-Swipe

After additional testing, I deduced that mechanism 4 was the best interaction for users to use. The other two took up more screen real estate; whereas the side-swipe allowed for a browsing method users were familar with, and an unintrusive save/discard mechanism.

The focus when creating a way to access a secondary search engine was to implement it in a way that was unintrusive, yet still easy to understand and notice. The original sketches in the early ideation phase wanted to represent the secondary search engines as logo icons. Simple logo icons would be difficult to decipher, so in the mid-fidelity mock-ups I tried using the full name.

Somethings that I kept in mind while designing these screens were:

  • Can the user easily transition between different search engines?
  • Is the current search engine clear?
  • Is the selection mechanism confusing? How can it be most transparent?

When designing the mock-ups for the search history, I wanted to utilize a folders system, as opposed to just having past search terms appear as users input text. Additionally, bookmarks are now designated as “search history” queries, but can further be personalized as folders with extended actions.

  • Search terms would be saved and hold the saved web pages within their folder
    • users can expand the folder to view the saved web pages
    • the saved webpages would function similarly to bookmarks
  • Search terms can further be sorted via groups
    • ex: “pad thai recipes” and “restaurants with good pad thai” could be combined into a greater folder
  • Actions with bookmarks

Some questions that were posed while designing these fidelity mocks were:

  • How to indicate the amount of saved webpages within the search history term?
  • How will users navigate opening saved webpages and then navigating back to the folder?
  • Should users be encouraged to delete search history terms if there are too many?
High Fidelity Mock-ups

Conclusion + Reflection

Through doing this case study, I was able to practice my user ethnography skills and apply them to the UX design process. Through my work on this concept app, I was able to take observations from interviews and user sessions and develop them into insights that were relevant in shaping the eventual design. Another learning experience that I took away from this case study was how to conduct testing for interaction design and understanding which interactions work best. A large struggle for this design case study was the visual design choices for the interface.

Card image

Rethinking Work From Home

Read the Hiven Redesign Case Study