以終為始：思考產品功能

Day 15 寫到，系統知道案件走到哪裡之後，還可以進一步幫使用者整理：

現在有哪些事情需要處理？

進到其中一個案件之後，我現在會再往下一層看。

不是先問：

「這個頁面要放哪些功能？」

而是先問：

這一步工作最後到底要完成什麼？

這個問題一清楚，畫面上需要哪些資訊、檔案和操作，也比較容易跟著整理出來。

先看工作的終點，不是先看現在用了什麼工具

有一個我印象很深的例子，是工作過程中的檔案交換。

原本有一段工作會透過個人 Email 收發檔案。

使用者收到信之後，要先下載附件，在自己的電腦上完成處理，再重新上傳到 Email 寄出去。

如果只是照著現有操作看，很容易想到：

「那是不是要把寄信功能做進系統？」

但我看到的重點不是 Email。

真正要完成的是：

把這份檔案處理好，讓案件可以繼續往下一步走。

既然這份檔案本來就是案件工作的一部分，我就直接把檔案交換放進案件處理流程裡。

使用者不需要先離開案件、另外進入一個獨立的檔案區，再想這份檔案和哪一件工作有關。

檔案就在這一步工作需要它的地方。

這也是我後來比較常用的思考方式：

先看工作要完成什麼，再決定功能放在哪裡。

每一個工作階段，需要看到的東西本來就不一樣

同一個案件在不同階段，需要處理的事情不一樣。

有些階段主要是確認資料。

有些要處理文件。

有些要新增這一步才產生的資訊。

所以我不希望一個案件頁從頭到尾都把所有資料、欄位、文件和操作全部攤在使用者面前。

我會先問：

現在這一步真正需要什麼？

這一步要看的資料，就放在現在。

現在要處理的文件，就放在現在。

目前不需要的資訊，不必因為它屬於同一個案件，就全部一起出現。

這個方向和我第一個產品時的經驗差很多。

以前我比較容易先想：

「這個功能做得到嗎？」

現在我開始多看一層：

「這個功能放在使用者現在這一步工作裡，真的有需要嗎？」

按鈕不是在叫系統換狀態，而是在讓人完成工作

這個想法也影響了操作文案。

案件往下一個階段走，系統內部當然需要更新狀態。

但使用者真正做的事情，不是：

更新案件狀態。

他可能是在：

• 完成確認。
• 送出資料。
• 提交文件。
• 把工作交到下一個人手上。

所以推進案件的按鈕，我沒有統一寫成「下一步」或「更新狀態」。

而是盡量直接寫這一步真正要完成的工作。

這和 Day 9 寫過的問題接得很直接。

系統內部怎麼處理，不需要原封不動變成使用者眼前的操作。

對使用者來說，按鈕應該說的是他現在要做什麼，而不是系統背後準備怎麼改資料。

還沒做完，就不要讓案件假裝往前走

知道這一步最後要完成什麼，也會讓另一件事情變得比較清楚：

什麼情況下，這一步還不能結束？

如果還缺必要資料，畫面就應該直接告訴使用者還缺什麼。

如果文件還沒完成，就不能只因為有人按下按鈕，系統便把案件當成已經進入下一個階段。

前面 Day 14 寫過，案件狀態不應該跟著每一個小動作一直變。

到了這一層，我關心的則是：

哪些事情完成之後，才代表這個工作階段真的完成。

工作的終點一旦清楚，這些條件也比較容易被看見。

工作往下走，資料也跟著往下走

同樣的思考也出現在資料上。

如果前一個階段已經確認過一份資料，到了下一段工作，它就應該直接成為後面的工作材料。

下一步只需要補上這一步新產生的內容。

不需要因為工作換了一個階段，就讓使用者重新把前面的資料再輸入一次。

需要產生文件時，也可以直接使用案件一路累積下來的資訊。

工作往下走，資料也跟著一起往下走。

這讓我開始比較少把功能理解成一個個彼此分開的按鈕或表單。

同一件案件裡，前面的工作會替後面準備資料，後面的工作也建立在前面已經完成的結果上。

產品要做的，是讓這些東西順著工作一起往前，而不是每到下一個畫面就重新開始。

我後來才發現，這些設計都從同一個問題出發

檔案為什麼直接放在案件工作裡，而不是另外做一套檔案管理？

為什麼不同階段看到的資訊和操作不一樣？

為什麼按鈕寫的是現在要完成的工作，而不是「下一步」？

為什麼前面已經有的資料會直接帶到後面？

這些看起來是不同設計，背後都在回答同一個問題：

這一步工作最後到底要完成什麼？

先把工作的終點看清楚，再往回整理：

現在需要哪些資料？

哪些文件？

哪些操作？

還缺哪些條件？

做到什麼程度，這一步才真的完成？

當時我只是順著工作這樣設計。

現在把這些做法放在一起看，我會把這種思考方式稱為：

以終為始思考產品功能。