我開始能從工作流程看見產品應該如何被使用

Day 14 寫到，我開始能沿著工作流程整理案件的不同階段，讓系統知道一件工作現在走到哪裡。

但對每天真正處理這些案件的人來說，知道進度還不一定夠。

他每天打開系統時，更直接的問題可能是：

我今天到底該先處理什麼？

這個問題，是委託人的回饋讓我更明確注意到的。

他們希望這套產品不只是把案件目前的進度整理出來，也能提醒哪些事情需要注意，協助他們判斷現在有哪些工作可以繼續往前推。

知道案件在哪裡，還是不一定知道現在要做什麼

假設系統裡已經有很多案件，而且每一件都標示了目前的工作階段。

這當然已經比原本更容易掌握進度。

但每天一上班，使用者還是可能需要自己從整張案件列表裡一筆一筆看：

這件現在需要處理嗎？

那件還在等資料嗎？

哪一件已經可以繼續？

有沒有哪一件快到期限，卻還卡在原本的位置？

系統知道每個案件在哪裡，不代表使用者已經知道自己現在該做什麼。

這時候，我開始從另一個角度重新看前面整理好的工作流程。

如果系統已經知道案件目前的狀態，也知道什麼條件成立之後可以繼續，那是不是可以先把「現在需要注意的事情」整理出來？

從案件列表往前一步，變成今天的工作入口

這個想法後來變成「今日工作台」。

它不是另一張把所有案件重新列一次的列表。

我希望使用者每天打開系統時，可以先看到：

哪些案件現在已經可以處理。

哪些事情正在等待。

有哪些工作需要特別注意。

今天可以從哪些地方開始。

一個承辦人同時面對的通常不是一件案件，而是很多處在不同進度的案件。

所以產品真正要幫忙的，不只是讓每一件案件各自顯示正確狀態。

還要從這些案件裡，替使用者整理出：

現在有哪些工作值得先看。

系統不是替人做所有決定

這並不代表系統要替使用者決定所有工作的優先順序。

實際行政工作裡，還是會有很多需要人根據當下狀況判斷的事情。

但如果系統已經知道某些客觀條件，例如：

案件現在走到哪個階段。

哪些資料已經到齊。

哪些工作還在等待。

哪些事情現在已經可以繼續。

那就不需要每天都讓使用者自己重新從大量案件裡把這些資訊整理一次。

系統可以先把可以判斷的部分整理好，再把真正需要人的判斷留給人。

這和第一個產品裡，我逐漸學會把固定條件交給系統處理的想法有點像。

只是這一次，系統不是直接替人完成某個固定操作。

它是在幫使用者整理：

現在有哪些事情可以開始做。

我開始從「產品怎麼被使用」來想功能

第一個產品時，我曾經把很多功能做得可以正常運作，最後才發現，那不代表真正使用的人每天就會用得順。

到了這個委託專案，我開始比較早把這個問題放進設計裡。

沿著工作流程往系統裡看，我會整理：

案件現在在哪裡。

什麼條件成立才能往下走。

系統需要記住哪些資料。

但往使用者這一邊看，我開始多問一題：

這些資訊最後要怎麼幫助他完成今天的工作？

這個差別也讓我理解，產品不只是把系統已經知道的東西顯示出來。

它還需要決定：

哪些資訊現在最有用。

使用者從哪裡開始。

什麼東西應該先被整理出來。

哪些判斷可以由系統先做，哪些仍然留給人。

系統記住案件怎麼往前走之後，我開始思考的，是產品要怎麼幫人把每天的工作往前推。

而進到一個具體案件裡之後，還有下一個問題：

這一步工作真正要完成什麼，畫面上又應該留下哪些東西？