交付當天對方說「非常完整，謝謝」。六個月後我們回訪，問起裡面的第四章建議，對方停頓了一下說：「那份報告我印象中是⋯⋯我再找一下。」那一刻我知道，我們交付的是一份沒有被使用的東西。
這件事對我們的影響很大，因為它揭露了一個誤解：我們一直以為交付的品質等於內容的完整度。實際上，一份沒有被使用的完整報告，價值低於一份被拿去開會的兩頁摘要。
五個問題裡最致命的是第四與第五。把結論放在最後是研究報告的寫法，不是決策文件的寫法。決策者需要的是先看結論，有疑問再往回查。
現在的標準交付結構是三層。第一層是一頁摘要：三個發現、三個建議、三件下週要做的事。第二層是十到十五頁的主體，每個發現一節，包含證據與推論。第三層是附錄，放完整的資料、方法與原始紀錄。
三層的用途不同：第一層給決策者，第二層給執行者，第三層給需要查證的人。同一份交付物同時服務三種讀者，而每一種讀者只需要讀他那一層。
最後那一行是我們後來加的，效果出乎意料。決策者最需要的其實是排序，而不是選項。願意替他排序，代表你真的做了判斷。
以前是寄一份檔案。現在是約一場三十分鐘的會議，當場走過一頁摘要，回答問題，然後才寄完整檔案。這三十分鐘讓報告從「一份文件」變成「一次對話」，被使用的機率完全不同。
改成三層結構之後，客戶的滿意度上升，但我們的工作量沒有減少，附錄的內容仍然要做，只是不再放在主體。真正改變的是資訊的排列方式。也就是說，這不是省工，是重新設計介面。
第四項最誠實，也最需要勇氣。但如果不問，你會一直以為自己交付得很好。
每一份交付物完成後，問自己一個問題：如果對方只有五分鐘，他能不能拿到最重要的東西？答不出來就重排。這個問題比任何品質檢查表都有用。
關於報告內部的章節安排，站內的 十二個章節各自回答一個決策問題 說明了以決策為單位的結構設計。
以一份中型專案為例：第一層一頁、第二層十二頁、第三層三十到五十頁。總量沒有比以前少，但閱讀的入口從八十頁變成一頁。這個差別決定了它會不會被打開。
第二層的每一節建議固定結構：發現、證據、推論、建議。四段、一頁以內。讀者掃過小標就知道這一節在講什麼，需要細節時才往下讀。
第二項是刻意的設計。示範一個完整的推論過程，比快速帶過三個結論更能建立信任，對方會理解這些結論是怎麼來的，之後自己讀其他章節時也有了框架。
附錄不是把所有素材倒進去。它應該是「可查證」而不是「全部」。每一項附錄都要能對應到主體裡的某一個論述，沒有被引用到的資料不必放進去。
實際做法是在主體的每個論述後標註附錄編號，附錄依編號排列。這樣讀者要查證時可以直接跳到對應位置，而不需要翻找。這個小設計讓附錄從「沒有人看的部分」變成「需要時真的會被用到的部分」。
交付物的品質包含兩件事：內容正確，以及被使用。多數人只在意前者，因為那是專業能力的展現。但一份沒有被使用的正確報告，對客戶的實際價值接近於零，這一點值得反覆提醒自己。
診斷型的分析：一頁摘要加十到十五頁主體。流程型的建議：一頁摘要加一份可執行的檢查表。策略型的建議：一頁摘要加三到五頁的推論，附錄放資料。
三種的共同點是都有一頁摘要。差別在主體的形式，診斷要證據、流程要可操作、策略要推論。用錯形式，即使內容正確也不容易被使用。
判斷方式很簡單：問對方拿到之後要做什麼。要向上級報告的，需要摘要與推論；要交給團隊執行的，需要檢查表；要自己判斷的，需要證據。
還有一個容易被忽略的細節：檔名。一份叫做「最終版_修正3_final」的檔案，在對方的電腦裡三個月後根本找不到。建議的命名是「客戶名_專案名_文件類型_年月」，統一格式，讓它在任何資料夾裡都能被搜尋到。這件事只需要三十秒，卻直接影響交付物的長期可用性。
再補一個後來的做法：交付前先寫一頁摘要，並且假設對方只會讀這一頁。如果一頁講不完，通常代表這份東西的結論還沒收斂，而不是內容太豐富。這個限制對我自己也很有幫助，它逼我在動筆之前先想清楚到底要對方做什麼決定。厚度曾經讓我覺得安心，後來才明白那只是把整理的工作留給了讀者，而讀者多半不會替你做完那一步。