なるほど、原本不知道的產品須知
在前日思考自己的汲汲營營所為何事後，覺得既然夢沒有追到的一天，能力也沒有技能樹點滿的一天，定期地給自己一些自我肯定也是必要。「なるほど！（原來如此！）」是近期在練習日文聽力時，podcaster 用來形容那些好像聽得懂、但原本都不知道其關連性的日文語法。這個角度很適合我，以下記錄自己在工作中原本不知道、後來產生更深層見解的一些事吧。
目次
1. 產品規劃與管理
2. Email 設計
3. SEO 入門一、建立產品規劃的準則
「好的產品設計，在於充分解決原本的問題。」這句如果是個迷因，標題一定是寫知易行難。
產品規劃難在定義問題。例如在登入系統提供使用者忘記密碼的設計，聽起來是解決忘記登入方式的 unhappy flow，但真正問題應該在於為什麼使用者三不五時「忘記登入方式」的窘境。以真正的問題出發，解決方案才會寬廣，如為其設想保有登入階段的機制，或是保有登入資料的機制。
定義好問題，構思解決方案也有其考量層級。最初階的思考當然是有多少開發資源做多少事（這就是我第一次面試產品經理時，被問到如何管理產品時的統一回答 XD）；但面對永無止盡的開發需求，得抓緊「先求有、再求好」的心態，避免整個團隊只在局部做得盡善盡美，卻忘記著力於整體的公司商業目標。
以初次開發退訂訂閱方案的流程為例吧。當團隊有工程師、設計師、產品等關係人參與，作為產品規劃者，固然會希望深入了解使用者退訂訂閱方案的原因，而構思了詳細的問卷邏輯；但是與其花費成本在不會再付費的使用者身上，更應該分配時間在「避免」使用者想退訂。流程完成之後，有需要細究退訂原因，則是之後可再做的事。
又比如今天在開發會員中心的管理電子報偏好頁面，假設希望能追蹤大家取消訂閱電子報的頻率好了（會有這需求ㄇ），如果 deadline 很緊，當然是得先開發好這個管理電子報的功能，再往後談追蹤的機制。不過當然，如果是在開發一個跟變現很有關的功能，如活動優惠頁面，這類的轉換率從第一天就很需要追蹤，那追蹤分析的機制就會是開發規格的必需品。
二、資安與使用體驗的平衡
以前在設計使用體驗時，都會希望降低使用者的認知負擔，最大程度地引導使用者。但是以登入系統而言，幫助使用者順利登入的引導，也可能等於引導駭客抓到登入系統的 pattern。
登入時輸入錯的帳號密碼時，應該分別顯示「你的帳號錯誤」、「你的密碼錯誤」或是綜合起來，寫「你的帳號或密碼錯誤」呢？顯示前者，駭客就能夠在確定 A 為正確的前提，只需要去試一個維度的組合；顯示後者，駭客就得兩個維度都去試錯。
當然，使用者可能會覺得「你的帳號或密碼錯誤」講了幾乎等於沒講，但你可以回頭從避免登入權限過期、利用第三方帳號登入、善用 keychain 登入來避免使用者落入這個情境。
三、減少開發成本的 UI 切版邏輯
以前對 UI 切版的認知停留在把圖 export 好就可以交付給工程師了，結果是好傻好天真。UI 切版的重要性在於讓工程師理解一個元件的組成邏輯，在 RWD 的變化下，哪些元件會延展、哪些元件會固定長寬並置左。因此交付設計圖面不代表完工，讓工程師看看你的 auto layout、variant 怎麼設定的才是重點啊。
事先設想周全，就不至於在未來已經開發完、上 production 後，才在不同的設備上發現元件爆版而得重新設計。簡單來說，正確的切版可以讓團隊少走很多試錯的時間成本。
四、保持簡潔儲存架構的資料需求溝通邏輯
連線的產品必然有要存哪些資料在 server 的漫長討論。比起產品直接開出欄位規格，明確表達儲存需求，才能幫助 server-side 成員思考對儲存架構的最佳解決方案。就像在介面上新增一個前所未見的按鈕，我們需要理解它的使用意圖是否已與原本的元件重疊、是否能被複用，以確保設計系統的簡潔易懂；儲存需求也一樣，要多存取一個資料時，幫助工程師釐清該資料的更新頻率、資料量、是否可能被拿來分析、資料型別，就會更好歸類在既有的儲存架構中。
Email 設計
一、在 email 體驗與通用性間取得平衡
欸怎麼突然跳到 email 了？阿最近就在碰 email，它可是潤滑產品 lifecycle 的重要一環啊。
email client 如 Apple 郵件、Gmail、Outlook 可以視為老舊的網頁瀏覽器，它們可能分別只適用某些 HTML 及 CSS。這些限制會造成使用者可能在 Gmail 能看到一個漸層圖片，在 Apple 卻只看到一坨黑。在眾多 client 中折衷出最大程度的視覺創意，仰賴 Can I email 以及模擬環境發信，一個一個測試。
email 的呈現可以分為 HTML 版本及 plain text 版本。我們視覺上可以因為 HTML 及 CSS 而看出信件結構的層級（如主副標、圖片等）但 plain text 就是純文字，用 screen reader 去理解這封信的結構會更好理解。如兩張功能說明的圖片，就最好在 plain text 寫上「第一點，這個風扇會涼；第二點，這個風扇風力很大。」plain text 的重要性展現在 email client 的預覽上。
plain text 為何重要？就在於 email client 在信件匣的預覽模式中，是依序呈現 plain text 中 subject, preheader 及 text 內文的。必須依賴空格，才能在視覺上獨立呈現 preheader；至於 Apple 相較 Gmail 等其他 email client 非常熱衷於讓空格無效，導致 preheader 跟 text 內文黏在一起，又是個神秘議題了。
二、更省成本的 mailer 選擇
在使用者的生命週期發送 email 是很司空見慣的事，但除了依賴第三方 email agent 設定發信，更省錢的做法可能是透過使用者 trigger 某些 API，讓 server 在這些時間點利用 mailer 統一發信，如註冊歡迎信、密碼重設信。適用 email agent 的時間點就比較是同一封信想做 A/B test、或與使用者生命週期無關的信件，如週年慶折扣。
三、發信給 Apple 帳號的小眉角
當使用者以 Apple 登入，又選擇 hide my email 時，使用者的收信信箱格式會變成以 @privaterelay.appleid.com or @icloud.com 結尾。這會讓開發商沒辦法得知使用者的真正信箱，必須向 Apple Developer 註冊已知 domain 後，才發信給該類信箱、並讓 Apple 轉寄這封信至這位使用者的真正信箱。
專案管理
一、Scrum 沒有固定形式，要將成員能力組成、速度、開發功能性質納入綜合考量
以往會一手擁抱敏捷開發、一手仍然畫出 waterfall 式的開發流程，以為功能必定由設計先做、接開發實作。口嫌體正直的傢伙啊你。
一切都等設計完稿才能付諸開發，那是設計師本身具備超強技術理解為前提所建立的流程。不同職能的來回討論基本上是家常便飯，如盤點 RWD 不同寬度下的元件變化、server 回傳的狀態呈現就是最常見的議題。
在 scrum 成員的討論下，ticket 的分配漸漸轉型，考量以下因素：
- team 內開發的多屬功能型情境、不需要太具創造性的內容
- 工程師具備一定的設計敏銳度，做出來的 prototype 基本上醜不了
- 開發上線速度目前是 ASAP。
我們將 ticket 分為兩種，一是實作先行，做出 prototype 後再由設計修正；二是設計先行，創造流程後定稿。以此確保每個 Sprint 的開發效率。
二、GitHub 作為純軟體的專案管理工具還不錯用
在 App、Web 類專案的所有功能開發都會 merge 進 code，以此為前提將所有的 ticket 都開到 GitHub 中。好處是更易追蹤每個功能開發的原始需求跟實作內容，但 GitHub 的專案管理功能尚屬陽春：
- Project 可以容納來自多個 repository 的 issue，但 issue 內的 milestone 卻只隸屬於單一 repository，造成每次都得去個別的 repo 新增 milestones 才能在 Project 統一管理相同 milestone 的 ticket
- Project 沒有 start date、due date 的標記功能，即使 calendar view 可以以單一日期將 issue 先後次序圖像化，卻無法表示出多於一天的期間觀念。這點請去跟 Slack 學學。
- Project 沒辦法同時設置多個 sort，習慣在 Done section 以 PR number sort 的我，面對沒有 PR 的 issue，就會希望能結合 issue number sort 來達成更友善的回顧。
三、還給大家 deep work 的時段
每個人都有手上需要深度專注才能完成的事，如 coding、設計，但外來的討論、請教及干擾是源源不絕的，此時除了效法 deep work 規劃出深度工作的時段，也可以在非同步工作時向對方明確表達自己的需求及預期回覆時間，讓對方掌握該需求的 pending 時間，自行安排空閒時間完成。
SEO
一、利用 GSC 觀察提高 CTR 的做法
為了讓官網文章更快累積流量，在有限預算無法提高 impression 的前提下，能做的努力就是提高 CTR。透過 GSC (Google Search Console)，可以找出 CTR 高的題材及 title、meta description 撰寫形式，以此發展往後的內容策略。搜尋結果呈現的更新仰賴 Google 索引，即使有送過 sitemap、robot.txt，但 Google 爬蟲執行的時間點、精確度難以預期，因此這方面的改善相較站內調整沒辦法立即見效。
二、利用 GA 觀察提高閱讀時長、降低跳出率的做法
為了讓 Google 等主要搜尋引擎認為我們的文章具有價值，可以從提高官網文章的閱讀時長、降低跳出率著手。透過每兩期回收一次的 GA，可以觀察排除掉 direct 流量後，自然流量的使用者閱讀情形。以此找出閱讀時長高的題材及文章編排準則；或從每兩週的介面調整來實驗最佳的閱讀體驗。
以前真的被 GA 層層疊疊的報表弄得昏頭，現在知道 GA 是以使用者的使用週期分段（客戶開發：使用者進站途徑 → 參與：使用者在網站上的行動軌跡 → 盈利：使用者變現途徑 → 回訪率：使用者留存趨勢）在我的「提高使用者在網站參與時長」的目標中，主要觀察的報表就是參與報表。
這邊推薦圖靈的 GA4 完全攻略，大大拯救了新手時期的我。
各個領域略懂略懂，繼續學習各個領域的語言吧。
