To Build Better Search, Develop Empathy With Your Users

Daniel Tunkelang
4 min readOct 16, 2017

--

User experience designers recognize the importance of empathy in the design process. Understanding how and why users engage with products yields insights that help UX designers evaluate and improve those products.

But empathy isn’t just for designers. It’s a requirement for everyone building products, especially in the software industry. I conjecture that one of the main reasons software products fail is that their developers didn’t make enough of an effort to empathize with their users.

And empathy is particularly important for search engine developers.

The primary interface for most search engines is a search box. While a search query is a strong signal of intent, it often leaves room for interpretation.

An Example

When I led query understanding at LinkedIn, we saw a fair number of search queries that were company names. LinkedIn used to direct such searchers to company pages that companies created in order to market themselves. As a long-time LinkedIn user, I had a hard time believing that millions of people were deliberately seeking out the mostly promotional content on these pages. I suspected that most LinkedIn members typing a company name into the search box were looking for a company’s employees and job openings.

My integrated team of software engineers and data scientists analyzed search sessions in our logs, and we found that most people who visited company pages were only doing so in order to find links to employees and jobs. Armed with this analysis, we enhanced autocomplete so that people typing in a company name would see suggestions like “People who work at…” and “Jobs at…” The increase in user engagement validated our offline analysis, and the feature is still on the site today.

Three Ways to Develop Empathy with Your Users

Developing empathy with your users requires a conscious and significant investment. Here are three things you can do to develop that empathy.

1. Use your product.

How can you possibly understand your users if you don’t use the product yourself? Common sense, right? Yet I’m surprised by how many search engine developers I’ve met who never use their products except to debug their code.

Use your product! Try to use it everyday — especially if you have personal or professional reasons to do so. Even if you don’t have a natural reason to use your product, strive to spend as much time as possible in your users’ shoes. Doing so will help you feel the pain your users experience with your search engine everyday — whether the cause is poor relevance, (lack of) spelling correction, high latency, or something else. It will also help you recognize the moments of delight you create when you’re doing things right.

But bear in mind that, as a search engine developer, you may not be a particularly representative user. Perhaps you access the search engine with a laptop when most of your users use a smartphone — and possibly not as modern a phone as your own. You might also know a bit more than most of your users about search operators, facets, and other advanced search functionality. Be a user, but remember that most users may not be like you.

2. Look at your logs.

Hopefully you already look at dashboards to track the aggregate search behavior of your users. If not, then start doing so at least weekly – if not daily. And if you don’t have dashboards to track aggregate search behavior, then build them. It’s a small investment that will provide massive returns.

But dashboards aren’t enough. Aggregate statistics are helpful, especially if you look beyond averages to more informative values (e.g., the 95th percentile for the metrics you track). But sometimes it’s hard to understand what your users are doing if you only look at statistics.

Look at individual queries. It’s amazing how much you can learn from a moderately sized sample (e.g., thousands) of queries. Try to make it a representative sample, but don’t be perfectionist about it. Look at short queries, long queries, and misspelled queries. Find out if queries contain unusual characteristics, such as numbers, punctuation, or capitalization. Look at queries that return no results and queries that return enormous result sets.

Then look at sessions, to see how searchers refine their queries. If you have access to user characteristics, try to relate those to their search behavior, especially if your users fall into highly distinct segments.

Finally, if you have the ability to do so, enhance your search dashboards so that, for any statistic, you can drill down to see a representative sample of the queries that comprise it. That will do wonders to help you see the whole story.

3. Talk to your users.

Search logs are powerful, and they’re the only cost-effective way to collect quantitative data about your product at scale. But sometimes you’re better off taking a qualitative approach and talking to your users.

If you ask a dozen users what they like and don’t like about your search engine, you’ll start to see patterns. If an issue comes up even twice, investigate it further. Much of what you learn will be redundant to your insights from log analysis. But you’ll also discover things that your logs can’t reveal, e.g., why users don’t perform certain kinds of searches using your product.

Don’t try to use these conversations to generate quantitative data about your product. Even if you talk to a hundred users, you’re unlikely to obtain statistically significant observations — especially if your conversations are informal. That’s not the point of these conversations. The goal is to catalyze insight — to help you generate hypotheses that you can test through log analysis and experimentation.

Summary

Use your product. Look at your logs. Talk to your users. But most of all, make an effort to develop empathy with your users. The more you understand how and why users engage with your products, the better you’ll be at building and improving those products. And by empathizing with your users, you’ll feel their joy.

--

--

Daniel Tunkelang
Daniel Tunkelang

Responses (1)