產品學習營來到第三週，這次 KKday 出題挑戰即便我作業寫完了，實際狀況不像夢境被全部同學無情只給 1 分，整體的衝擊還是相當大，其中有夥伴跳脫框架令人耳目一新的洞察與解法，跪著看完的觀摩，當然也少不了抖 M 的導師點評。
同學們後續討論也有幾個過程中的難關與我自己的反思，除了這次報告以外，或許也是面對產品時會特別費心的難題。
訪談對象決定優化方向
訪談對象數量要夠多，才能足以代表產品用戶，但是在有限的時間內到底可以找到多少受訪者，代表性程度又是多少，過程中我時常自我質疑，這真的是大多用戶面對產品的場景嗎？
而這些用戶的行為要透過歸納分類，例如親和圖等模型收斂進行抽象化，但是這些用戶屬性到底是保留還是捨去呢？時常在此陷入膠著。或許在每個夥伴重複遇到同樣的用戶情境，就不要天人交戰，勇敢決定。
User Journey 從接觸點發揮
在經歷用戶旅程時無論是自家產品或是替代產品都應該納入，但有可能遇到使用頻率不高的情況，該不該腦補進來，理當不行，但如此一來痛點該去哪找呢？如果接觸點不足，是否要再找另一群人？那是要重新訪談還是重新拉一次 User Journey？
如果不是因為小組需要共用，我可能會把訪談時對產品有許多接觸點的用戶為 User Journey 主角，借鏡替代產品的使用情境與功能，再深挖痛點與解法，雖然不曉得錯還是對……
認知邊界影響規劃完整度及深度
因為是實際產品的功能優化，在功能的可行性其實受到許多未知的技術限制，很多時候過於理想化，解法的背後所需的成本很難預估，到底需要考量到多深對我們而言相當困難，也牽涉到自我認知範疇，對產品甚至技術層面的掌握度不高時，解法就相對狹隘。
比方說我們想以新功能取代舊功能，但何以已得知的呢？有數據佐證嗎？現實狀況一不慎可能演變為：風聲傳到該功能的團隊中，啊你憑什麼拔我功能啊，當時我們熬夜做了多久知道嗎？又引來一場腥風血雨。
從六週壓縮到三週似乎是更精實，讓你更密集的感受對現有產品設計難以割捨的苦痛，面對相對短缺的時間資源逼自己做決策。
我想起幾年前 AppWorks School 學 Swift 時，晚上睡覺夢到還在 coding，如今夢到在 Evonne 面前發問然後大家只給我 1 分的無情場面，無論 App、Web、SaaS、IoT 真的都要用感恩敬畏的心使用每項產品，那是用多少人的腦力（焦慮）換來的。
於此同時已不要求自己精準解題，大概是冀望能用正確的邏輯去思考、看待產品，一道道難題彷彿一片片槓片，蹲下去、扛起來，為產品肌肉做重訓，鍛鍊過程會自我懷疑、往臉上甩八萬個巴掌，或是落入無法跳脫的誤區，當作重訓的菜單吧。
留言