|
One thing to note is, the less users use a feature, the less you understand how exactly they do it. Of course from a saas point of view, it’s easier to serve most and forget about least (we are here). But technically, only n% of users have advanced tasks that require a dozer on their lawn, because their “lawn” was not meant to have a grass or a kids playground on it from the start. If you sell a product that initially has a dozer in it, it will be bought by 88 home owners and 12 construction sites, because it fits both. If you then remove a dozer, or even put it into “easily accessible place”, construction sites will stall, because their speed depends on having that thing always present on site. As one example, search engines respect quotes less and less with years. So even if you quote few words, you may not find it anymore. Another example is my bank app that combined searches from different pages into one omnisearch field. Before that, I could simply go to a specific card and search for “digi” to see recent digital ocean payments with dates, and screenshot it to my accounting guys (also scaleway, kamatera, you name it). Now I have to scroll through “suggestions this week” (ads) with random “digi” in them, and then tap on every DO payment, because some of them are my own expense (on a different card), and I can’t see dates in a list anymore, because “date” is a property of a payment, and omnisearch searches for all kinds of items, and their common class doesn’t have a date, so to speak. They broke it for me, because now instead of one “shutter-send” I have to wait for 5-15 REST queries to complete and shutter-send each of these, confusing my accounting, because they also prefer lists with dates. Not to mention that omnisearch may not show some items for an unknown reason, and that I have no idea who wanted to search for ads and other crap in a bank app, instead of having well-partitioned searches together with a proper omnifield. |