Skip to content

Search home in simple UI

Created by: quinnkeast

This is a subissue for #39554.

Problem statements

  • We’ve observed that for new users, Sourcegraph's core search workflow is unintuitive and unfamiliar, which results in a steep learning curve and poor first experiences that are unlikely to result in a personal "aha" moment.

  • Similarly, we've observed that existing users often lack—and struggle to build—confidence in searching with Sourcegraph, which limits the value they get out of search. For these users where search is their primary entry into Sourcegraph, a poor search experience will make it less likely they'll explore beyond search and discover the full value Sourcegraph provides.

  • As part of the "Simple UI" effort, previous explorations have been removed from the search home. We assume the "Simple UI" will ship by default in 4.0. While removing these previous explorations helps achieve the higher-level goal of reducing perceived complexity in the core workflow, the original problems these explorations aimed to solve remains.

  • While Cloud will eventually provide us with the means to experiment and iterate on a faster cycle, we must assume that the solution we ship in 4.0 will be likely to be used by many customers for a several month period before they upgrade.

  • "Lucky search" (https://github.com/sourcegraph/sourcegraph/issues/38363) is our solution-in-progress for eliminating the "no results" outcome when a user unfamiliar with Sourcegraph's query syntax attempts a search that doesn't align with how Sourcegraph works. However, lucky search should not be a solution for initial learning and education, because it relies on the user "failing" as a first action.

Additional context and constraints

  • We have ~1-2 weeks to explore and land on a meaningful solution to this problem to ship in 4.0 (with space for iteration and refinement ahead of launch). While there are almost certainly many ways we can solve this problem, we should favour a high-impact but tightly scoped solution space in the short term over broader changes.
  • This is a known and ongoing challenge we have with our search product. We have previously explored solutions (such as the search tour, onboarding checklist, search home panels) to similar problems, and haven't found a solution that has proved to solve this effectively.
  • A summary of previous actions and outcomes can be found in this GDoc.

Design challenge statements

  • How might we provide new users with a specific search goal with an obvious first action that will start them on the path to a successful search?
  • How might we provide new users who don't have a specific search goal with a starting point that will lead to better long-term understanding of how Sourcegraph works?
  • How might we approach product education with idea that all users are constantly learning?
  • How might we make it easy to get started with search for developers at different stages (early to experienced) of their career?
  • How might we build on top of an existing user's learning, without distracting from their goal at hand?

Hypotheses

  1. A search home that includes only the search input will make it harder for new users to succeed with Sourcegraph.
  2. In the context of our current UI paradigm, the most important concept for new users to understand is how Sourcegraph's search is filter-driven.
  3. The first search from the search home will either correctly or incorrectly establish the mental model.
  4. As different users have different search goals, while specific search examples are useful to help users understand the potential of search, those same examples are unlikely to be immediately useful in a given immediate search goal. Surfacing actionable and composable starting points will help users break out of the "blank white page problem" and get them onto the path of a successful search outcome.
  5. Preserving a user's previous searches is valuable for reducing friction in starting future searches. Surfacing this in the moment of intent rather than as a constant will encourage better learning in line with the above, while also avoiding additional complexity-by-default.

We’ll know this is true if:

  • New users report positive sentiment in relation to their first few searches.
    • This needs consideration. It's something that may be determined through qualitative feedback in user testing, or perhaps there's an in-product prompt, or there may be other opportunities.
  • In user testing with new users, the number of successful first search experiences for a given activity increases against the current new user experience.
    • It may be we don't have time to validate this against a control, so it could be a more binary outcome—in user testing with new users, users consistently experience a successful search outcome. This is more subjective but the process of testing would help us to iterate.
    • "Successful first search experiences" will need to be defined in the context of this work.
  • The number of successful searches by new users over the course of a (defined time period) increases (suggesting ongoing retention rather than optimizing only for the first search).
    • A "successful search" will need to be defined in the context of this work.
  • The average session of a first-time user is ≥ X and includes successful searches, indicating they were in a positive feedback loop with the product.
    • This will also need consideration for how to evaluate, because an iterative search is not necessarily an unsuccessful search. We may need to again rely on qualitative feedback here to start.

Design exploration