Showing search results than can be parameter names (like "size") or values (like "big")

Question

Consider the following page:

The user can use the search to find items or to filter the table. If the user wants to find a person whose "name" (parameter) "contains" (logical operator) "lis" (value), the name "Elisa" must be shown. The user then clicks on the result and is sent to the "Elisa" page.

The caveat is that we must also show "parameters" by the same logic, regardless of values. For example, if I search for "ame"; "Amelia" must be shown (since it is a name that contains "ame") but "Name" itself, as a parameter whose name contains "ame", must also be shown as a selectable option (the user then defines the "value" for "name" in a subsequent step).

My question is how to best present these results. One approach I've seen used before is dividing the results into columns, one for each parameter:

Note that "listing status" is shown as a "result", since its name contains "lis", but also as a parameter, since two of its possible values also contain "lis".

This approach, in my opinion, has the benefit of being more, "results-focused", being more common (and, in theory, better understood) and more straightforward.

On the other hand, if you have matches in a lot of parameters, they just won't fit the horizontal limit; which might imply results not being shown straight away. Also, if the user selects a parameter, it will be mandatory to send him or her to a "next step" to specify values.

Another approach:

The left "column" shows attributes whose name match the search, and also attributes that have values that match the search.

If an attribute/parameter whose name is a match is selected on the left, the user can specify a value on the right and confirm that as a filter. If an attribute that has values that match is selected, the values that match are shown on the right and clicking on them confirm that parameter/value pair as a filter.

The example shows attributes whose name match the search being shown on the right, and clicking them would have the same effect as selecting them on the left (I'll probably scrape this scenario and just show values on the right).

This approach is more convoluted, but maybe better organised. It's also more robust in tackling scenarios in which a great number of parameters might be present, while also allowing some space for specifying values directly.

So, if anyone could have any insights of prior projects in which a similar problem was presented, I'd love to hear about your results or other approaches to this kind of search.

Cheers!

Answer 1

This feels almost like an additional search parameter (and results), which seems only necessary when you have a lot of parameters, some of which are not clearly defined or known to the users. Otherwise, you could simply design a left side panel like a lot of e-commerce site (e.g. Amazon) where you list these parameters and you can return results filtered on those parameters.

Regardless of the path the user takes, it would appear that the end goal is to get to an actual entry, rather than a parameter. Hence getting to a result via a parameter first is just an alternative search path, since some users might find it easier to associate an item with a particular set of parameters rather than the exact value like an ID or model number.

You'll have to test this on users of course, but my guess is that if the list of parameters is already defined and doesn't change much, it is better to already have them listed rather than appear in such a way when the user is typing in search terms. This also means that you can use this list to narrow down the search results already, and then use them to further narrow down the results if required.

If you only implement this display after the user has entered in search terms, then you are limiting an option for the user to get to the end result quicker.