第一性原則對產品發展之影響 — 以 Figma 為例
產品設計的一大重點是溝通、凝聚團隊共識。身為設計師，我們的超能力是視覺化大家腦中模糊的畫面，明確定義細節以求達成商業、使用者體驗上的目標。在凝聚共識時相當忌諱任何不同步、溝通上的誤會。想當然地，設計稿作為一個溝通工具，確保所有團隊成員能及時取得最新版本，作為 single source of truth 是相當重要的事情。
Figma 從產品很早期的特點就是即時線上共編設計稿，我認為也是後來異軍突起的原因，而這就是在產品路線規劃時是否運用第一性原則思考的一大差別。以下是我個人的不負責任推測：
Figma 團隊運用第一性原則拆解出產品設計的重點：溝通，因此即時共編具有相當高的優先級，也是他們起初和其他產品做出區隔的方式，而後續發展也證明他們當時的選擇是正確的。
其他設計工具的開發團隊（例如 sketch）起初對標的是當時市場已存在的圖像編輯軟體，例如 Adobe Photoshop，他們選擇延續當時其他軟體已有的檔案管理架構，每個人把檔案存在自己電腦裡面，使用者自己傳檔案、進行版本管理等等。做競品研究或對標競品常常能對產品規劃帶來幫助，但也有其缺點。
因為當時沒有汽車，所以人們想要的是更快的馬，亦即更方便的檔案版本管理。當汽車（即時共編）出現時，檔案管理的重要性也就減低了。
除了檔案版本管理之外，Figma 相對於其他產品特別強調「透過網址快速分享設計稿」、「跨平台都可以使用」，因為他們拆解本質後，明白產品設計不是設計師一個人的事，所以不該像 sketch 一樣只能在 MacOS 上使用，工程師、PM、Biz stakeholder 都應該能夠簡單打開檔案並同步資訊。
Figma 讓設計流程更加民主化，當然也某部分加重了設計師的溝通頻率（或負擔😇），例如任何人都可能跳進 Figma 裡面留言、發問。解釋設計決策後的思考脈絡、背景、方案優劣累積起來是不小的工作量，也進而成為部分設計師選擇採用 Figma 時的疑慮，該如何更有效率地進行利害關係人管理成了更重要的課題。我實際聽過公司選擇不使用 Figma 的原因是如此，所以這個功能帶來的並不完全是產品優勢。
隨著程式能力的逐漸普及、越來越多的 No-Code 工具誕生，如何安排產品優先級、產品策略的思考會顯得越來越重要，影響產品發展的關鍵點更重於做什麼，而不是怎麼做，Figma 的發展就是一個活生生的例子。
不過我所想到的也可能只是藍色窗簾 😇，例如 Figma 看到 Google 做了雲端文件，所以覺得設計工具應該也要能夠即時共編之類的。或者是他們有好好做需求研究，發現設計師們真的覺得版本管理很麻煩。
讚誒你看完了我的 mur mur。以上是某日坐飛機時太無聊的突發奇想，希望你也覺得有趣。
