「如果意見不合的話會以誰的為準？」忘記是在哪場面試還是座談之類的場合，有人問到 READr 內部如何決策時，主管神色自若地回答：「讀者啊。」
這是產品經理邀請我寫改版筆記時，我想到的第一個畫面。聽到的當下，第一次發現這個問題有這麼適切的答案，所以記得特別清楚。
「使用者」是必須謹記的咒語
當然現實一定沒有這麼理想啦（可能有同事開始 OS：哪有⋯⋯上次⋯⋯），這比較像是一個理念，且必須時時刻刻提醒自己的咒語。不過，從我加入這個團隊時，每一次的專題或產品檢討，除了看數字以外，也在數字裡面認識讀者的樣貌。例如，我們從點擊率發現要讀者額外點開的功能使用率都很低，從此非不得已不再採用類似的設計、從閱讀深度改進報導字數（真的有變少啦）等等。
而這次參加 Google 育成工作坊開始的網站改版旅程，算是再次貫徹了使用者優先的概念。所謂貫徹，是到後期想到一個新的概念，都有像唸咒語般地自問、也質問同事們：這真的是使用者要的嗎？或者只是我們自己想像出來的？
無論是最一開始密集的實體特訓、還是後來每週的視訊上課，Google 的工作坊教會了我們各種認識使用者的方式，如何將使用者訪問化為一個個實體的人設，再將這些人設轉化為行為，進入產品設計中的各種細節裡。更重要的是，開發之後，要怎麼持續滾動修正？這時，就要設計各式各樣的指標，來確定你能從使用者的一舉一動中知道他們真正的心意。而又要避免過多資訊讓使用者感到厭煩，像極了愛情。
意識到內容產製需要極大彈性
其中讓我最印象深刻的，是意識到現今的內容產製需要多大的彈性。某次在腦力激盪時，是同樣的內容轉化成不同的長度和形式（大家也實際想出了何謂「不同的長度和形式」，包括閱讀時間 5 分鐘、15 分鐘、30 分鐘或是純聲音、純影片等等），來滿足不同需求的讀者。
雖然產品經理當時要我們先不要想可不可能達成，否則會侷限了創意。但當時我心裡實在是歷經了一場小革命（？），一邊想著，這的確就是必要的彈性啊！如果你真的對這個題目融會貫通，那轉化成不同的長度和形式一定是可以的；但同時也在想，實作上真的做得到嗎？如果要能達成，記者還需要什麼樣的訓練跟素養？
“Release early, release often”
作為記者，在過程中還有兩個不斷衝擊思維的點。第一，是有時候使用者根本不在乎、或搞不清楚你做的很多事。例如，標示報導為專欄、為短篇、為深度，或是各種花俏的單元名稱，除非你有一個老品牌，或是長期教育讀者，否則會在意、或分辨得出來的讀者真的是少數。那麼，有沒有更直覺的標示方式？又或者，讀者在選擇文章的時候到底會在意什麼？
第二個，其實也是我加入這個以工程師為大多數人的團隊之後還是有點不習慣的事。或許是作為記者，也或許是個性使然，我常常覺得東西一定要完美才能發佈。但這個團隊的產品，包括跟我有關的新聞協作，有時候常常會先發佈首波，剩下的功能待第二波、第三波才繼續做完（不是報導，報導一定經過嚴格檢驗啦）⋯⋯不知道大家還記不記得，我們的政治獻金專題，當年也是先發佈了資料，才推出報導⋯⋯
但在工作坊時講師講得很明白，與其在那裡糾結，或做再多的焦點使用者測試，既然事前能做的都做完了，不如直接發佈，讓真正的讀者群體告訴你哪裡好、哪裡不好。說不定你糾結得要命要盡善盡美的功能，讀者根本不在乎；又或者是無心插柳的小功能卻成為了讀者的心頭好，這時才發現，就算團隊再大、提點子的人很多，還是會有盲點。
所以，這一版的 READr 當然不會是完整版（或許永遠都沒有完整版？），期待你們的使用，雖然聽起來有點變態，但我們會在後台仔仔細細觀察你們的樣子～（喂）。