上一篇文章，我談到怎麼觀察微光有沒有變好，而不只是看訊息數量增加。

如果真的開始留意使用情況、閱讀回饋，很快就會遇到下一個問題。

值得改善的事情，好像不只一件。

有人找不到入口，有人提出新的活動玩法，角色還有可以調整的地方，某個功能也讓我想到另一種可能。每一項單獨拿出來，都有繼續做的理由。

但時間和心力有限，我不可能同時把所有事情往前推。

寫到這裡，我想談的就是這個選擇：當想做的事情很多，怎麼決定下一步先做哪一件？

值得留下的想法，不一定要立刻開始
第九篇談過，收到建議之後，我希望先把它整理成可以判斷的計畫。

到了真正要選擇時，還需要多做一次取捨。

一個想法有價值，和現在適合投入，是不同的事情。有些需要其他功能先準備好，有些會帶來目前還無法承擔的維護工作，也有些只是我很喜歡，卻還不知道成員會不會用。

如果只要覺得不錯就立刻開始，最後可能每件事都做到一半。

表面上開了很多工作，成員能實際使用的東西卻沒有增加多少。我自己也得不斷切換背景，重新想起每個項目上次停在哪裡。

所以，我希望待辦能幫助選擇，而不是不斷提醒自己有多少事情還沒做完。

先留下來，也可以是一個完整的決定。

先把已經讓人卡住的事情看清楚
如果既有功能讓人無法繼續使用，我傾向先處理這類問題，再安排新的內容。

但「先修問題」也需要具體判斷。

有人只是覺得多按一次很麻煩，和有人已經被扣款卻拿不到商品，影響並不一樣。牽涉隱私、權限或資料正確性的問題，也不能因為使用人數少，就一直往後排。

我想先了解誰受到影響、目前能不能繼續，以及如果不處理，會發生什麼事。

這樣才比較容易分辨，哪些是需要立即停止風險的問題，哪些可以安排改善，哪些則能先保留一段時間。

聲音比較大、最近剛被提起，不應該成為唯一的排序依據。

從一個使用情境開始，不從一大包功能開始
假設我觀察到，有些新成員看完介紹之後，仍然不知道可以先做什麼。

我可能立刻想到很多解法：重新安排頻道、增加引導角色、設計教學任務，再做一張互動地圖。

這些都有可能有用，但全部一起做，範圍很快就變大了。

我想先把問題縮回一個能描述的情境：

「一位第一次接觸微光的人，看完入口說明之後，能不能找到一項感興趣的內容，並順利開始？」

這裡是用來說明取捨的假設例子，不代表我已經確認它是微光目前最優先的問題。

當情境比較清楚，就可以先試一個較小的改善。例如，整理出一份簡短的開始指南，讓每個選項直接連到可操作的位置。

先確認這樣能不能幫上忙，再決定是否需要更複雜的引導系統。

先問，這次最想弄清楚什麼
有些工作是為了修正已知錯誤，有些則是在驗證一個想法。

兩者的完成方式不太一樣。

如果交易流程有問題，就需要確認問題被修正，相關情境不會再出現。若是在嘗試一種新活動，則不只是把活動辦完，還需要觀察原本的期待有沒有發生。

所以，選定工作時，我想同時寫下這次要回答的問題。

以開始指南為例，可以是：「成員看完之後，是否知道下一步要去哪裡，而不必再問一次入口？」

這比「改善新手體驗」更容易檢查，也能幫助我避免中途一直往裡面加東西。

不是每個有用的點子，都需要在同一次嘗試裡完成。

規模可以小，但要讓人完整走過一次
縮小範圍，不是只做半個流程。

如果有入口卻沒有下一步，或可以提交卻永遠得不到結果，成員仍然無法完整體驗，也很難提供有意義的回饋。

因此，我希望選的是一小段能從頭走到尾的事情。

可能只支援一種任務、一個情境，或一小群事先同意的參與者，但開始、處理與收尾都要清楚。

至於必要的權限檢查、資料保護與錯誤處理，也不能因為「只是先試試看」就省略。能縮的是功能範圍，不是把風險轉交給使用者。

這樣得到的結果，才比較接近真正使用時會發生的事情。

把這次不做的事情也寫下來
計畫很容易在進行中慢慢變大。

既然做了指南，是不是順便加上個人化推薦？既然有任務入口，是不是再做進度面板？每個建議都和原本的工作有一點關係，很難只靠直覺判斷該不該加。

所以，我想在開始時，也留下這次不做的部分。

例如，這次只確認入口是否清楚，不重寫世界觀、不增加新的獎勵機制，也不替所有功能重做介面。

把界線寫出來，不代表那些想法不好，而是讓這次工作有機會結束。

如果中途發現原本範圍真的不足，就重新評估，不假裝只是順手多做一點。新的需求，也應該有自己的取捨。

把驗證、收尾和維護一起算進去
估計工作量時，我很容易先想到製作本身。

寫一段程式、整理一頁說明，或準備一場活動，可能看起來不需要很久。但測試、確認結果、處理回饋，以及之後的維護，也都會占用時間。

如果只替製作安排空間，完成之後的事情就容易被下一個新點子擠走。

因此，我想把一項工作的投入，算到可以交付並確認結果的位置，而不是只算到「做出來了」。

也需要先知道，如果試用後發現問題，這次還有多少調整空間。不是一開始就承諾無限修改，直到所有人都滿意。

有明確的停止點，反而比較容易負責任地開始。

做完之後，可以繼續，也可以先停下來
一次嘗試結束，不一定要自然接著擴大。

如果結果有幫助，可以保留，再看下一步值得補什麼。如果效果不明確，可能需要更多觀察，也可能是問題還沒理解清楚。

若發現原本的解法不適合，就可以停止，留下學到的事情。

我不想因為已經投入時間，就一定要替它增加更多功能，直到看起來像成功。也不想在反應不如預期時，立刻把責任推給成員沒有照想像中的方式使用。

實際使用和想像不同，本來就是試做能帶來的資訊。

重點是知道差別在哪裡，以及接下來是否還值得投入。

沒有先做的，也需要一個清楚的位置
選擇一件事，意味著其他事情暫時不做。

對提出建議的人來說，如果沒有說明，可能會以為自己的意見被忘記了。因此，我希望能區分：這項建議仍在評估、正在等待必要條件，還是目前決定不採用。

不一定每一項都能提供日期，也不應該為了讓人安心，就給出還沒有依據的承諾。

但至少讓對方知道，收到了，不等於已經開始；暫時沒有開始，也不代表沒有人理解他的意思。

這樣，待辦才比較像協助判斷的紀錄，而不是一份不斷累積、卻沒有人知道何時會兌現的承諾。

下一步小一點，才看得清楚要不要再往前
這個系列寫到現在，從故事、角色一路談到任務、可靠性與維護，確實累積了很多可以繼續發展的方向。

但這些文章是思考的整理，不是一張要求自己同時完成所有內容的施工清單。

真正要開始下一步時，我仍然需要回到微光目前的情況，確認哪個問題最值得處理、能投入多少，以及怎麼知道這次有沒有幫上忙。

先選一件，不是因為其他想法不重要。

而是我希望有一件事情，能被好好理解、完成，交到使用者手上，再把結果帶回來。

比起同時宣布很多準備開始的計畫，我更想慢慢累積一些能夠確定的改變。

讓下一次選擇，不只靠期待，也有上一次實際走過的經驗。