Search is one of those things that can take a week, or a year to design and implement, so before you start it's a good idea to gauge the scope of what you can achieve, and plan accordingly, for example if you only have a week, then it's likely you're building a simple search feature for pros as you won't have the time to add all the things that make search good for beginners (like filters).When used well, search can be an exceptionally powerful tool for organising and locating data. In certain situations it is in fact the only reasonable way to achieve certain workflows. However, search can also go wrong, so I'll get the warnings out of the way first, and then I'll give some examples of how to get search right.Firstly, without hand-holding (more on this below) search is a task active method of finding things. E.g I know what I'm doing, and I know how to do it. So if one of those isn't true for your user, and you're not holding their hand, that means search is only useful to advanced users of your app. Navigation should thus be available (via menus for example) so that inexperienced users can still find what they need.Secondly, search increases the memory load as it compels recall over recognition. Search also has a high interaction cost (typing over clicking) and is error prone — spelling errors, or recall slips — you should allow for this in search fields by allowing approximate spellings. You should also consider allowing for recall slips where a user searches for a synonym, for example if a user type's box into a feature search field but you actually have a feature called cube, not box, you can obviously use system traits to show the cube result anyway.Finally, search is not enough, never make the only way to access something be by typing it in a search field. This will seriously hurt discoverability; search should not be a crutch for a bad IA.Let's take a look at some search examples...