資訊架構講座主題:新的需求討論工具, iA 速寫討論法

初次公開舉辦「資訊架構入門講座」的感想

講座的主題內容是講解我們家的產品設計流程,關於如何從需求還很抽象的狀態,逐漸透過設計討論的方法,讓情境中的「功能」與「內容模組」被識別出來,進而逐步完成資訊架構設計。

七月份的時候終於初次舉辦了資訊架構講座,寫下這篇文章作為感想紀念。

這幾年我一直在琢磨去發展資訊架構相關的需求討論技巧,起因是我們身為 UX 設計的乙方,設計師也只有小貓兩三隻,並且接案生活最麻煩的地方就在於會有淡旺季。

閒的時候,某一年我們還通通放暑假,把案子集中趕完之後,大家各自出國玩一個月把工作室整個空窗。

忙的時候,有一次我們同時跑九個專案,每個案子的進度不一,產業別以及規模也不一樣。

接案過的人都知道,很多時候專案估時是個假議題,因為我們永遠只能算清楚「自己做」要花多少時間,而接案其實是甲乙方的兩人三腳遊戲,你不能只顧著自己快速前進,要客戶的認知也跟上才行。

講白話來說,設計其實可以做得很快,但再怎麼快的快手,也怕改。

但其實資深的設計師通常都會有備案,保留修改的彈性,所以怕的不是改,而是大家都摸不清楚為什麼而改,或者什麼樣的程度修改是合理的?現在討論的修改影響幅度有多大?

資深的產品開發者可以用經驗去估算這些影響以及預見可能的問題,但就像前面說的,接案其實是甲乙方的兩人三腳遊戲,要客戶的認知也跟上才行。

所以我們不能憑直覺就告訴客戶:「這樣修改有問題。」

客戶只會認為你在擋他需求,造成雙方的利益不一致,落入了尷尬的對抗局面。

其實沒有人是笨蛋,當然知道修改會造成風險,但是做出錯誤的東西沒辦法達成目的,許多人是無法背負這樣的責任的。

那麼,我們該如何站在客戶(需求方)的立場,幫助他們一起辨別哪些修改是合理有彈性的?哪些修改會產生大範圍的變動呢?

上述的原因,就是這次講座中,我們提出新的 iA 討論工具的緣由。

我們稱之為「iA 速寫討論法」,這個方法承先啟後,介於 UserFlow 之後,Sitemap 之前。

主要的訴求是透過具體情境討論,辨識出為了實現這個流程的用戶目標,系統應該準備哪些功能機制,以及這些功能機制背後的內容欄位需求、組合規則是什麼。

透過這個討論法,設計師不需要在聽完需求之後,去觀落陰生出畫面來,工程師也不用等 wireframe 都畫完了,才來一個畫面一個畫面的拼湊整體資料需求,回頭冥想系統架構。

簡單來說,就是紮實的走穩每一步,盡可能讓需求在推進過程越來越清晰。

身為接案方的產品設計公司,這些年經歷各種產業別的產品開發案,我們也經常要跟陌生的工程師們合作。

陌生的產業、初次合作的客戶、第一次認識的工程團隊,這些都是軟體開發上的風險因素。

這個時候,好的設計流程,就是為了幫大家認知對齊,降低溝通的風險。

能夠把這個流程整理出來,跟業界朋友分享,對我來說已經是快成為心魔一樣的怨念了。

大概從兩年前開始我就在思考著,該怎麼把這個工作流程變成明確的框架呢?一面想著這樣的目標,每次我在新專案中,就忍不住進行各種嘗試,希望抓出一個我自己能說得清楚的模式,而不是憑經驗與直覺來討論。

其實在七月初我決定辦這場講座時,心理也還在發慌,因為我還沒有找到適合的角度來說明這個討論法的架構。

講座當天還在驚慌失措的準備簡報

硬著頭皮給自己壓力,上週五在講座之前的白天,我還在趕製簡報,甚至因為來不及製作,所以根本不是在 Keynote 上,而是在平常做設計稿的 Axure 上面製作簡報內容。

突然之間我在那個下午,進入了心流的狀態,順利的找到一個敘事觀點,大致說明了整個故事。

感謝當天在線上聆聽講座的七十多位業界朋友,我收到了非常豐富的回饋以及想繼續討論的議題。

這些問題我會整理之後,陸續寫成文章來一一討論。

有興趣收到之後講座消息的朋友,也歡迎留下你的聯絡資訊:https://prodigious-builder-6290.ck.page/d2c732f947

產品設計師以及 UX 教育講師。Hahow線上課:https://hahow.in/cr/think-with-ux , 工作聯絡:charm.soking@gmail.com