Search is product design

Search looks like infrastructure until it fails in front of a user. Then it becomes product design very quickly.

The same text box can mean completely different things depending on the workflow. A dispatcher looking for a job number, a support person looking for a customer, and a recruiter looking for a candidate are not doing the same kind of search. They have different mental models, different shortcuts, and different ideas of what a good result looks like.

I have seen simple details matter more than fancy ranking. Does search ignore formatting characters? Does it understand the number the UI shows, not just the raw database value? Does it search the field a user remembers, like a phone number or address, instead of the field an engineer happened to index first?

Generic search often misses these details because it treats the data as documents. Workflow search should treat the data as objects with jobs to be done. The right answer is not always the semantically closest result. Sometimes it is the invoice number, the service address, the technician name, or the one object that can unblock the next action.

This is why I like search problems. They force the product and the system to agree on what users actually know when they are trying to find something.