資訊架構學是什麼？

這邊試著用解構的方式來說明資訊架構 (information architecture) 這門學問。

設計活動就是在某些限制下，生出某個東西來達成某個目的的過程。

所以可以理解「設計資訊架構」的過程中，設計出來的某個東西指是「架構/結構 (architecture / structure)」、而且這個架構的改變對象是「資訊」(information)，接著透過新產生的「資訊互動」達成我們的目的。

簡單說，資訊架構透過設計「結構」、讓人和「資訊」有不同的互動，來達成我們背後期望的目的。

舉例來說：
1. 程式碼的資訊架構
結構：檔案命名、目錄名稱、放的位置、如何引用、設計模式
資訊：程式碼
目的：讓程式碼容易被理解、容易修改、容易查找、容易維護

2. 網站的資訊架構
結構：搜尋列、標籤、sitemap、瀏覽列、超連結、分頁...
資訊：文章、圖片、服務、功能
目的：讓人能找到想要的資訊、讓購買率上升、讓使用者達成他想做的行為

3. 書本的資訊架構
結構：段落、內容的順序、章節、標題、註解
資訊：文字、圖
目的：讓人更能透過閱讀能理解內容

4. 愛買的資訊架構
結構：商品走道的規劃、服務台的位置、結帳的位置
資訊：商品、愛買提供的試吃服務
目的：賣出更多商品

5. 臥室的資訊架構
結構：物品的擺放位置 (櫥櫃裡、牆面)
資訊：物品
目的：主人想...

資訊是相對的
對不同的人，同樣的資料會是不同的資訊；在不同的環境(context)下，同樣的資料會是不同的資訊。資訊不光只有資料、在電腦科學裡，功能/函數也是資訊的一種。

設計的目的是多方向的
有設計者本身的目的、有對使用者的目的、有對其他關係人的目的。也就是說，只要是跟人相關的活動都要理解這些人想要的是什麼、目標是什麼。和使用者中心設計 (User-Centric Design) 一樣。

設計模式 (Design Pattern / Design Principle)
只要是設計就會有比較好的設計模式來增加設計的成功率。所以通常我們在資訊架構中所學的就是這些「架構的設計模式」，對不同的資訊、不同的目的、不同的人都會有不同的「架構的設計模式」。評估一個「架構的設計模式」的方式就是觀察資訊擺在這個架構下，資訊到底會有什麼不同，能達到什麼不同互動。

被架構後的資訊
資訊經過架構後還是資訊，資訊的不同點不外乎就這些：資訊容易不容易「理解、瀏覽、找到、關聯、傳遞、同步、容錯、不失真、記住、更新、處理、新增、刪除...」 根據不同的設計目的，設計不同結構，讓原來的資訊的這些面向變得不同，以達成我們的目的，這就是資訊架構學的使用方法。

Domain Knowledge
架構的設計模式太多了、資訊也太多種類、人也太多種，細節就看相關領域的書吧~ 只是時時記得，有「變動世界的架構」的選項，變動後一切就會變得不一樣。就像 google / facebook，完全改變了人們和資訊的互動方式、產生方式。

facebook的資訊架構
結構：News feed & notification 系統 & 好友列表
資訊：發文、按讚、分享、加入社群的行為、閱讀時間
目的：讓世界變得充滿萬惡的讚能量、讓人都只看到自己想看的

最後說一下，其實設計流程是結構的一種、結構也是資訊的一種，從資訊流動來看世界是不是越來越有趣了呢？下圖是資訊架構和其他領域的關係。

在使用者經驗分層中，每層都是息息相關的，如果哪一層壞了，整個就壞了。所以從上圖我們可以知道：要做好資訊架構，我們必須做好設計研究、對內容有了解、對功能有能力去實作；要展現好的資訊架構，我們必須做好互動、介面、資訊、視覺設計，不然光只有好的架構，使用者經驗不會好。所以... 工作的時間到了。

參考：
1. Eight Principles of Information Architecture, 2010 - Dan Brown
2. Information Architecture 100, 2013 - 長谷川敦士
3. The Elements of User Experience, 2010 - Jesse James Garrett
4. Information Architecture: blueprints for the web, 2009 - Christina Wodtke and Austin Govella

台大不一樣思考社：設計思考工作坊 Day 2

組合虛擬人物 （CC）

第二天一早 Recap 的方式就是，從前一天的三個人物中合成一個叫 Jessica 的虛擬的人物 ( Composite Character )，這部分是很主觀的，先基於從現有列出來的 needs 和 insight 選出覺得有發展性的點。最後再藉由腦補內容、畫使用者畫像，像是 Persona 一樣把虛擬人物立體出來，因為花了一整天生出來的人，大家其實對他很熟悉 ( 比隨意的 Persona 熟的多 )。

腦力激盪  (Brain Storming )

CC有幾個 insight，最後選的 insight 是現代人會 Do something 來填補早餐的空白時間、像是滑手機，所以腦力激盪的目標變成就是想出一個「讓早餐時間不是空白時間」的方法。之後就是「不批評」「不打斷的」「不離題」的 Brain Storming 了。因為有了 Jessica，這個每個人都熟悉立體人物，溝通的時候變得方便很多，就像是有了使用者的原型一樣。Brain Storming 就是爽爽的啊，不過這次特別強調了「要延伸」他人想法、「要畫圖」要有「Title」等重點。

發想的差不多後，用「強迫聯想」的方式做 Brain Storming，這部分也是蠻新奇的，先列出「教室」和「辦公室」裡的不相干用品，然後強迫生出可以滿足人物 insight 的想法，這邊會先卡住，然後只要有人開始分享，就會變得很多神奇的想法出來。最後再把所有的想法大概有 100 個吧，一人數票投票列出幾個、然後在二次投票，二次投票的時候才想起 Jessica，想哪一個想法比較可能滿足她。最後選擇用動的食物吸引注意力的迴轉壽司早餐。(好像是小隊輔提出來的... XD) 還有設定要驗證的幾個小想法，像是少量食物、多樣組合 blah 的

製作原型 (Prototyping)

快樂的 30分鐘 maker 時間，高級的扮家家酒和演戲，多次試驗。大家都玩開了~ 我只能說大家的手做能力很強大。

請使用者測試 ( Testing )

這步真的讓我看到 Prototype 的威力所在，第一個使用者就發現這個原型對使用者的感覺，雖來一進來就盯著移動中的食物，但跟我們思考的不一樣。因為迴轉壽司早餐比較像是有空閒時間才會去的地方，對想省時間的使用者。另外還有會發覺原型的問題，像是輸送列應該一開始就要有早餐在上面、最好加上文字說明。除了輸送列的早餐外，還要有菜單、送茶水的服務生不用帶位，特別強調是週末，悠閒的週六早上十點之類的情境。修一修加上演戲，原型多少有解到空白時間的問題，在第一個 iteration 應該算是不錯吧。

各小隊火力展示 ( Demo )

很意外的是其他六隊都做 App，而且有試著嘗試去解我認為早就被解完的問題：「有效率地得到早餐。」本來以為台灣早餐店林立、便利商店林立，早餐不用跑很遠、更不用自己做，還會剩下什麼需求沒被滿足嗎？結果是「熱騰騰好吃的早餐店要排隊」，於是就寫個注重體驗的訂餐、捷運門口取餐的App，然後第一次實體看到 App 的 Prototype長什麼樣子，點點點、換頁之類的，想到我做網頁、寫 App 錢真的也該先做好 Prototype 找個使用者來用用啊~~~

結語
這個工作坊是個團隊討論、體驗設計思考流程的好地方。本來以為價位有點高 ( 和我以前辦其他社團活動比 )。不過看到一組請三個陌生人使用者來受測、中午吃的還不錯、設計 conference 都很貴、1:2 的教練學員比，總總因素來說是 C/P 還不錯的。列一下 pros and cons：

pros:

• 可以深入的練習觀察技巧
• 思考使用者的需求和需求背後的原因
• 快樂的團隊思考、討論體驗
• 大量便利貼的利用技巧
• 得到一種完整的設計流程體驗
• 真實的和使用者接觸
• 小隊輔們還蠻用心的
• 可以碰到許多願意用溝通、用設計改變世界的人
• 小遊戲很好玩
• 一直放舞曲很High

cons:

• 和現實真的有一段距離 (感覺 TA 是學生)
• 像「人本機構」的只鼓勵、不批評的環境讓「擁抱失敗」變成口號。
• 建立「需求」、「insight」、「CC」，的過程中用了大量的假設，推論一錯就 GG
• 完全不做現有解法的比較與調查 (像是摩斯訂餐 App)
• 不介紹失敗的例子
• 過度強調人本，但除了人的需求。技術和商業的重要性都不說明，一個好的偵探除了觀察和推理能力，對事物的知識也是很重要的。
• 只有練習三個人以上的團體技巧。

---

有點小進步，不過感覺和 Design Researcher 的路還有好遠好遠。
最後有點太專心討論和解題，好像沒有好好認識其他人啊，有點可惜~

心理系的小隊輔一江、設計感的 Jarah、到處出現的 Boy、強大的設計師 美辰、很有主見的獸醫系 元皓、講話有趣的東璋、眼鏡很帥的財金系 軒凱、討厭心智圖但會組織演講的柏儒，這次有點忘記一期一會的決心...

記得感到痛苦和累的時候，稱讚一下自己吧「你努力離開舒適圈了喔 :p」

台大不一樣思考社：設計思考工作坊 Day 1

和藝術不同，設計是一門客觀的學問。重視觀察、基於觀察做出像偵探一樣的推論、做出像科學家一樣的假設，用同理心而不是同情心去理解這一個人的行為和需求、從使用者的角度去看這個世界。

問題是和需求是不同的：

從8層樓高優雅的降落到地表不受傷是一個問題。但大多數人這輩子都不會有這樣的需求。


需求要用動詞來描述而不是名詞：
需求：「吃到好吃的早餐」 => 人自動會把行動連接成

1. 怎麼 「吃到好吃的早餐?」
2. 為什麼要 「吃到好吃的早餐，原因是什麼？」

需求「好吃的早餐」 => 推理就的莫名其妙的卡住，加上 5W1H 都很不順！




今天請大家解的題目是「如何提升吃早餐的經驗」。

流程：
   1. 先用便利貼討論要訪談使用者的問題、把相近的問題Group後，針對每一類問題畫正字投票.

   2. 街訪：會有一個主訪、副訪和紀錄。大概十分鐘，主訪負責掌握進度、副訪負責見縫插針。

   3. 把數個人紀錄的資訊口述下載，每個人寫下事實 (Fact) 到便利貼上 & 分類。

==== 以下開始小組討論、瘋狂的 blocking I/O 超花時間，為什麼不繼續平行計算啊 ====
   4. 試著從事實 (Fact) 中，推出這個人的需求 (need)
   5. 從這個人的需求 (need)，找出洞察  (insight)

[來到了 long long complain section]
一人一票決定街訪問題，真是不太好，就是一種讓人膚淺思考的快速解決方式吧、然後想問題的時候，好像沒有一個比較好的想法，怎麼問會得到提升早餐經驗的資訊，不過強調 empathize 那這次就不預設立場試試吧

從列需求就一直卡，用動詞描述真的很重要 ( 回家才看文章才懂 )，然後訪的幾個學生都不是很愛吃早餐，他們的簡單需求早就在這個台灣早餐文化發達、便利商店充斥的環境滿足了。還說「提升早餐體驗」是簡單題目，結果需求列完，洞察完全列不出來。需求出來就解啊，為何要落在為做「設計思考」強說洞察的陷阱裡，Inception 一定要下到第幾層嗎？不過別組有些很順利的，希望明天報告的時候能搞清楚，我們和別人不同在哪？做錯了哪一步？

另外一個是「提升早餐體驗」的題目定下來了，我們不知道客戶是誰、沒有辦法詢問客戶，沒法想問題背後的問題 / 找到真正要解的問題。然後一開始也沒決定是要生產品還是服務，也沒有定好 TA。最後我們這組 TA 好像是學生，但如果要解這個問題，自身的經驗、非訪談的觀察就不能使用。

然後很討厭，台上報告有事沒事後面工作人員就很 high 的附和之類的，做設計一定要這樣搞嗎？不過開始前玩小遊戲提神真的還不錯。

現在的想法就只有，使用者都想跟朋友一起吃早餐，那就請宿舍早餐店提出兩人同行，第二人早餐六折的優惠，這樣所有人的體驗都會好，早餐店也會比較賺錢。

---
現在只能安慰自己，花了 1,600 元兩天就發覺 Design Thinking 沒啥用，也是不錯的收穫，反正還有一堆其他的設計流程。 UX 這條路 QQ 回家重看了設計的心理學的 Design Thinking 一章，特別強調不要用訪談耶...Orz


Don't try to be original, just try to be good.
I don't want to be interesting, I want to be good.
( 不一樣思考又怎樣啊... 解問題為什麼不先 google / survey? )


明天就是嘴砲的 brain storming~ to be continued.

延伸閱讀：
像福爾摩沙一樣解決社會問題 (同情心、同理心、觀察力)
Problems Are Not Equal to Needs
Don't try to be original, try to be good.