系統知道怎麼做，不代表使用者就該這樣做

前幾篇寫到，我越來越習慣把人的工作往下拆。

系統需要知道哪些資料？

什麼條件成立之後才能繼續？

現在進行到哪一步？

下一步應該做什麼？

這讓我越來越容易把複雜工作真的做進系統裡。

但後來我才發現，這種思考方式也會帶來另一個盲點。

當我越來越習慣按照「系統要怎麼一步一步處理」來想事情，也很容易把同樣的順序直接做成使用者的操作方式。

我把系統需要知道的東西，一步一步問給使用者

當時櫃檯的功能都放在 LINE 裡完成。

主要操作方式是一張選項卡片接著一張選項卡片。

使用者先從選單進入某個功能。

選完第一組內容，系統再根據前面的結果顯示下一張卡片。

一路往下，直到需要的資料和選擇都確認完成，才執行最後的操作。

對當時的我來說，這種方式很合理。

因為我自己在實作功能時，本來就是這樣拆的。

例如要修改一筆預約，系統可能要先：

找到正確的個案。

找到對應的預約。

確認這筆預約現在能不能修改。

再執行後面的更新。

既然系統本來就是一步一步判斷，我也很自然地讓使用者一步一步跟著走。

系統下一步缺什麼，就再問一題。

下一步還要確認另一個條件，就再多一層操作。

而且這些功能真的可以運作。

資料拿得到。

不同條件會走到對應流程。

最後的預約也能正確更新。

所以我很容易覺得：

「這個功能已經做完了。」

mentor 看完後只說了一句：「這樣太工程師了」

有一次，我把這套操作方式 demo 給 mentor 看。

他看我走完一段多步驟 LINE 操作之後，跟我說：

「這樣太工程師了。」

他建議我重新從一般使用者怎麼完成工作來想操作方式，也提到可以考慮用 Web 介面承接比較複雜的操作。

真正讓我留下印象的，不是「要不要改用 Web」。

而是那句：

「太工程師了。」

因為我第一次注意到：

我正在要求使用者，陪著系統把內部處理流程走完。

系統需要怎麼處理，和使用者要怎麼完成工作，是兩件事

還是拿修改預約來說。

系統背後當然可能需要：

找到個案。

找到預約。

確認狀態。

檢查條件。

最後更新資料。

但櫃檯真正想做的事情可能只有一句：

「我要修改這一筆預約。」

系統背後需要查幾次資料、經過幾層判斷，並不是使用者真正關心的事情。

那些是系統為了完成工作必須處理的細節。

不一定都要變成使用者眼前的一個步驟。

這時我才第一次很明確地分開兩件事：

系統需要怎麼一步一步處理。

以及：

使用者需要怎麼把一件工作完成。

這兩件事情可以完全不同。

系統內部有很多步驟，不代表介面也要有很多步驟

這個差別一看見之後，我開始重新看原本那些多步驟操作。

以前我會想：

現在系統還缺一項資訊。

那就再顯示一張卡片讓使用者填。

接著還要確認一個條件。

那就再進下一層。

從程式處理流程來看，這樣沒有問題。

但對使用者來說，一件原本很直接的工作，可能因此被拆得很長。

他不需要知道系統現在缺什麼。

也不需要跟著每一個內部判斷一起前進。

如果那些資料本來就可以在同一個畫面看到，或者系統自己就能先完成一部分確認，就不一定要把每一層邏輯都做成一次使用者互動。

系統內部的複雜，不應該直接變成使用者操作上的複雜。

「大家本來就會用 LINE」也不能回答所有問題

這也讓我重新看自己一開始為什麼那麼喜歡 LINE。

當時最大的理由很直接：

大家本來就會用。

不用另外學一套新工具。

這個理由本身沒有錯。

LINE 的確降低了很多使用門檻。

但我開始多看到一個差別：

使用者熟悉某個工具，不代表每一種工作都適合被做成這個工具裡的操作。

簡單查詢、通知、單一步驟操作，和需要大量資訊、反覆比較、管理多筆資料的工作，本來就可能需要不同的介面。

我當時還不知道最後應該怎麼分。

也不知道哪些工作應該繼續留在 LINE、哪些要移出去。

但至少第一次知道：

「大家會用 LINE」不能直接推出「所有工作都應該在 LINE 裡完成」。

我開始多問一個問題

在那之前，我檢查功能時最常問的是：

流程有沒有跑完？

條件有沒有判斷正確？

資料有沒有更新？

那次 demo 之後，我開始多問一個問題：

如果真的有人每天使用這套東西，他會想用這種方式完成工作嗎？

我原本一直在學怎麼把人的工作拆成系統可以理解、可以執行的流程。

做到這裡，我才第一次明確看見：

系統知道怎麼做，不代表使用者就該照著系統的方式做。