初次公開舉辦「資訊架構入門講座」的感想
講座的主題內容是講解我們家的產品設計流程，關於如何從需求還很抽象的狀態，逐漸透過設計討論的方法，讓情境中的「功能」與「內容模組」被識別出來，進而逐步完成資訊架構設計。
七月份的時候終於初次舉辦了資訊架構講座，寫下這篇文章作為感想紀念。
身為乙方設計公司最大的困擾在於需求變動
這幾年我一直在琢磨去發展資訊架構相關的需求討論技巧，起因是我們身為 UX 設計的乙方，設計師也只有小貓兩三隻，並且接案生活最麻煩的地方就在於會有淡旺季。
閒的時候，某一年我們還通通放暑假，把案子集中趕完之後，大家各自出國玩一個月把工作室整個空窗。
忙的時候，有一次我們同時跑九個專案，每個案子的進度不一，產業別以及規模也不一樣。
接案過的人都知道，很多時候專案估時是個假議題，因為我們永遠只能算清楚「自己做」要花多少時間，而接案其實是甲乙方的兩人三腳遊戲，你不能只顧著自己快速前進，要客戶的認知也跟上才行。
講白話來說，設計其實可以做得很快，但再怎麼快的快手，也怕改。
但其實資深的設計師通常都會有備案，保留修改的彈性，所以怕的不是改，而是大家都摸不清楚為什麼而改，或者什麼樣的程度修改是合理的？現在討論的修改影響幅度有多大？
資深的產品開發者可以用經驗去估算這些影響以及預見可能的問題，但就像前面說的，接案其實是甲乙方的兩人三腳遊戲，要客戶的認知也跟上才行。
所以我們不能憑直覺就告訴客戶：「這樣修改有問題。」
客戶只會認為你在擋他需求，造成雙方的利益不一致，落入了尷尬的對抗局面。
其實沒有人是笨蛋，當然知道修改會造成風險，但是做出錯誤的東西沒辦法達成目的，許多人是無法背負這樣的責任的。
那麼，我們該如何站在客戶（需求方）的立場，幫助他們一起辨別哪些修改是合理有彈性的？哪些修改會產生大範圍的變動呢？
我們需要新的資訊架構討論工具
上述的原因，就是這次講座中，我們提出新的 iA 討論工具的緣由。
我們稱之為「iA 速寫討論法」，這個方法承先啟後，介於 UserFlow 之後，Sitemap 之前。
主要的訴求是透過具體情境討論，辨識出為了實現這個流程的用戶目標，系統應該準備哪些功能機制，以及這些功能機制背後的內容欄位需求、組合規則是什麼。
透過這個討論法，設計師不需要在聽完需求之後，去觀落陰生出畫面來，工程師也不用等 wireframe 都畫完了，才來一個畫面一個畫面的拼湊整體資料需求，回頭冥想系統架構。
簡單來說，就是紮實的走穩每一步，盡可能讓需求在推進過程越來越清晰。
身為接案方的產品設計公司，這些年經歷各種產業別的產品開發案，我們也經常要跟陌生的工程師們合作。
陌生的產業、初次合作的客戶、第一次認識的工程團隊，這些都是軟體開發上的風險因素。
這個時候，好的設計流程，就是為了幫大家認知對齊，降低溝通的風險。
能夠把這個流程整理出來，跟業界朋友分享，對我來說已經是快成為心魔一樣的怨念了。
結語
大概從兩年前開始我就在思考著，該怎麼把這個工作流程變成明確的框架呢？一面想著這樣的目標，每次我在新專案中，就忍不住進行各種嘗試，希望抓出一個我自己能說得清楚的模式，而不是憑經驗與直覺來討論。
其實在七月初我決定辦這場講座時，心理也還在發慌，因為我還沒有找到適合的角度來說明這個討論法的架構。
硬著頭皮給自己壓力，上週五在講座之前的白天，我還在趕製簡報，甚至因為來不及製作，所以根本不是在 Keynote 上，而是在平常做設計稿的 Axure 上面製作簡報內容。
突然之間我在那個下午，進入了心流的狀態，順利的找到一個敘事觀點，大致說明了整個故事。
感謝當天在線上聆聽講座的七十多位業界朋友，我收到了非常豐富的回饋以及想繼續討論的議題。
這些問題我會整理之後，陸續寫成文章來一一討論。
有興趣收到之後講座消息的朋友，也歡迎留下你的聯絡資訊：https://prodigious-builder-6290.ck.page/d2c732f947