微信試圖用小程式來重新定義服務路徑的長度。過去幾個月，業界一直在討論微信對小程式的定義：即用即走、觸手可及。這一度讓開發者疑惑，因為如果微信你期待我做的產品是即用即走的，那為什麼我要開發小程式？難道產品不該想辦法黏住用戶麼？
這種疑惑，是因為很多人把眼光放到了「即走」上面。事實上，好的產品用戶自然會回來使用，不必花小伎倆留住用戶，就像Google，你不會因為它給你提供了精準的搜尋結果「即用即走」了然後再也不用，相反，下次想搜尋時，你還是會打開Google。所以問題就變成，我們要怎麼讓使用者判斷我們的產品是好產品？
用戶的時間很寶貴，要讓用戶第一次使用就喜歡我們的產品，顯然要讓用戶在最短時間裡感受產品的核心，判斷是不是他想要的，而不是：
開啟app，預設看幾秒鐘廣告
第一次使用需要花時間註冊
功能層層堆疊，難以找到
就像寫文章一樣，如果讀者沒有在短時間內判斷文章的價值，他就可能停止閱讀。
所以，如果我們做的產品確實是好產品，問題回到了「即用」上面，如何讓使用者馬上感受產品的好？
答案是 — 建立最短路徑。
如果我們認同，幫用戶節省時間的產品是好產品，那麼，服務號碼就不是一個好產品。
我明明只是想買一張汽車票，我需要掃碼關註一個買票的服務號，關注後我需要花時間尋找買票的菜單，然後可能還需要註冊才能完成付款。為什麼不能掃碼後直接購買？為什麼要先關注？為什麼不能在武漢掃碼就預設選擇武漢出發的票，在北京南站掃碼就默認選擇北京南站？
小程式沒有關注功能，它所期待的，是用戶掃碼後立即獲得服務，就像張小龍在演講時舉的例子，掃碼後立即購票，不用關注，也不用花時間尋找購買按鈕，甚至，掃碼後自動用微信帳號登錄，連註冊的時間也省下來。
相較之下，小程式比服務號更節省使用者時間，縮短了使用者獲得服務的路徑。使用者在整個過程中是暢快且愉悅的，當他下次需要服務時，自然會想起曾經「即用」過的產品。
從這個角度，我們可以推斷，微信之所以要逐漸用小程式取代服務號，是因為服務號並沒有為使用者建立比 app 更快的服務路徑，沒有節省使用者時間。
更多微信小程式想要最短服務路徑相關文章請關注PHP中文網！
