這是資訊架構學–網站應用，第三版的第十章：研究(Research)，前面己章都在講解觀念和元件架構，從先在開始課本要介紹建造資訊架構的流程和方法了，這一部份看起來比較對ㄚ琪的喔。eh，讓我們開始吧。
流程概觀
上圖是一個擷取來的資訊架構開發的流程圖，研究->策略->設計->實作->管理是整個的程序，但是專案會只到實作的階段，ㄚ琪不想打太多字在每個階段的敘述，由圖應該可以很簡單地看出接下來的流程。但是最隱ㄚ琪興趣的倒是這句話話，『在網站設計的早期，很多公司採取單階段流程，名為「撰寫HTML」。』ㄚ琪應該也算這樣子的人吧，不過我很清楚目標的設定，可是這個設定，不會是像我這樣的網頁程式設計師做的，所以大部分也是與我無關的，我可能比較著重在設計跟實作等階段吧。
研究框架
ㄚ琪發現用圖解來分享心得其實算是不錯的idea，不過大部分只能找到英文的資訊，算是比較不利華人吧，不過ㄚ琪可以大概說明一下中文的意義，另外也就不太需要進行詳細的說明，真是好用。
三圈圖是作者很喜歡用的圖示的一種，課本接著會講解
Context（情境）：考量到商業目標、資金、政治、文化、技術、人力資源
Content（內容）：考量到文件/資料類型、內容物件、中介資料、資料量、現存結構
Users（用戶）：考量到觀眾、任務、需求、資訊搜尋行為、經驗、詞彙
要實作這個三圈圖，這裡又有個矩陣圖分析每個模式使用的工具，對於工具來說，應該是我輩中人喜歡的吧。
情境：背景研究、會議和報告、投資人面談、技術估價
內容：探索式評估、中介資料和內容分析、內容對映、標竿
用戶：搜尋紀錄和點閱路徑分析、使用案例和人物、情境式查詢、用戶面談和用戶測試
看起來除了搜尋紀錄和點閱路徑分析ㄚ琪比較有感覺之外，其餘都覺很煩，而且很抽象。
接下來會依照這樣的順序再細部分解。
情境
跟情境有關的政治問題就是「以管理階層為中心的設計」VS 「以用戶為中心的設計」，我想哪個孰盛孰優應該很容意辨認。
令人信服
這一節這個主旨，ㄚ琪算是在業界打滾多年之後所獲得的經驗，增強你的口才以說服你的敵人同意你的想法，這是最高招，也是最高境界，想把事情做得少，口才一定要有，出這張嘴非常必要。
背景研究
『檢視背景材料是好的開始。』
初步簡報
沒想到花時間作簡報是值得的，學起來了。
研究會議
真沒想到還可以分成三類的會議：
策略小組會議
『策略小組要設定高階目標，定義任務、願景、觀眾、內容，和功能。這個小組要處理的就是在中央和地方之間取得平衡。…面對面的會議是必要的。…五到七人是最理想的。…會議的關鍵之處就是你嗅到了什麼。』
我用以上幾個簡短的摘錄以表示ㄚ琪所瞭解的事。
內容管理會議
這些問題可以列成一張checklist，所以請看課本的詳細介紹，會很有幫助。
資訊技術會議
投資人面談
這裡的面談屬於非正式討論，討論的問題ㄚ琪也不再贅述。
技術評估
『你會想知道有什麼現存的東西，流程中有什麼，誰可以幫得上忙。然而，你可以做落差分析(gap analysis)，找出商業目標、用戶需求，和現存技術基礎架構的實際限制之間的缺口處。』
什麼是落差分析？課本突然冒出這樣一段話，用英文去Google可以發現有時也翻成差異分析，ㄚ琪看了之後大概可以清楚其意義，也感覺是商業的工具手法，所以就不再多說了。
內容
『內容大致定義為「網站上的東西」…
用戶必須能夠找到內容才能使用，可尋性位在可用性之前。如果你想建立可尋性物件，必須花時間研究這些物件。必須找出物件之間的區別，以及文件結構與中介資料如何影響可尋性。你會想在這種由下而上的研究，與對網站現存資訊架構由上往下的觀點之間取得平衡。』
探索式評估
『重新設計既存的網站，…有機會站在別人的肩膀上。可惜的是，因為人總是習慣把焦點放在錯誤上，而且有想從頭開始的慾望，所以，常常錯失這種機會。』作為一個接案者為了生存，不可諱言地，『如果客戶把他們的網站視為垃圾』，我們一定要順從客戶的意見，把舊思想、舊東西批的體無完膚，這樣我們才能有機會建構新思想、新的網站，這才是機會，這是ㄚ琪與課本持不同的方向，因為這是從獲利的角度著眼的，沒有對錯。
不過這種從現存網站找到東西來的的工具，還是得上手。
『探索式評估(heuristic evaluation)是一種專家判斷，以一組正式或非正式的設計準則測試網站。最好是讓某個局外人做評斷，這樣才能不帶有色眼光看事情，而且沒有政治因素的可量。理想上來講，檢視背景材料前，就要做探索式評估以避免偏見。』
看起來這個錢是一定要花的，本想省起錢來自己捲起袖子動手幹，看起來是不可能的，如果自己做，很可能落入自我感覺良好的情形。
可以參考Jakob Nielsen的Ten Usability Heuristics (http://www.useit.com/papers/heuristic/heuristic_list.html)，ㄚ琪列出這十點：
- Visibility of system status
- Match between system and the real world
- User control and freedom
- Consistency and standards
- Error prevention
- Recognition rather than recall
- Flexibility and efficiency of use
- Aesthetic and minimalist design
- Help users recognize, diagnose, and recover from errors
- Help and documentation
ㄚ琪以為若是沒有財力，用這個指導方針似乎不錯，或許還可以無師自通。
內容分析
『內容分析可以非正式調查或細節式的稽核。在研究階段初期，高階的內容調查，是瞭解內容的範圍與本直的一個有效工具。到了後面的流程，一頁一頁的內容稽核或者清點可以產生一個移植的路徑，把內容移植到CMS(content management system)，或者至少有一個便利的組織化方法，進行網頁層級的寫作和設計。』
這兩種方式似乎只有點出初步的作法，但是的作法好像沒有，也不知後面有沒有，ㄚ琪先Mark起來留待後續查考。
收集內容
『為了開始作業，必須找出、列印、分析網站內容中具代表性的樣本。…
我們建議採用諾亞方舟(Noah’s Ark)法。
下面是一些建議，可以從中找出樣本：
- 格式：目標是各種格式的混合。
文件類型：最高優先權應該是找出一群多樣的文件類型。
來源：樣本應該反應出內容來源的多樣性。
主題：找些專門針對業界設計，可用的公用分類體系或彙編詞彙。
現有架構：
注意一個因素報酬遞減率。』
分析內容
這裡頭敘述的作法也不大清楚，僅提到參考的事項：
- 結構化中介資料
描述性中介資料
管理性中介資料 - 要精通這個方法，還是靠自己多摸索了。
內容對映
現在，是發展內容對映圖，把探索式評估所瞭解的網站的組織和導覽結構跟內容分析中所瞭解網站的內容物件連接起來的時候了。
內容對映圖(content map)是對現存資訊環境的視覺表達法（如圖所示），其實在這一章中，有鑑於敘述資料很多而且很細，ㄚ琪在這章中還算滿多敘述圖解的，一來也方便，二來可以節省打字，三來確實可以從圖看出重點，這就是ㄚ琪想要分享的心得，否則你就自己買書來看就好了。
內容來源(content sources)考量到行銷、顧客服務、法律。
內容模型(content model)考量到產品、流程、參考。
內容類型(content types)考量到聯絡處理、系統用法。
內容範本(content templates)考量到步驟、表格。
標竿
這一節看起來ㄚ琪覺得比較重要，引用課本這段話：
『標竿(benchmark)…指要做一些比較性衡量或研判…。在此情境下，標竿牽涉到系統性的鑑定、評估，以及網站和企業網路的資訊架構特色之比較。
這些比較可能是量化或是質化。我們可以評估，用戶在使用對手網站執行任務時所需的秒數，或者記下每個網站最有趣的特色。「比較」可以是不同網站之間的比較（競爭性標竿），也可以是相同網站不同版本的比較（前後性標竿）。就此二例而言，我們發現標竿是相當有彈性而且有價值的工具。』
競爭性標竿
『這裡的重點是，從競爭對手那兒借用資訊架構是有價值的，但是，必須很謹慎。』書本自行敘述這是重點，ㄚ琪就不用很麻煩地摘錄及分享了，而且這也確實是ㄚ琪慣用的方法。
前後式標竿
這裡列出兩種標竿的優點，Google不到資料，所以辛苦地打出來囉
『
- 在現存網站中，可以找出資訊架構特色，並突顯其優先地位。
從廣泛的一般化描述（例如，「我們網站的導覽系統臭名滿天飛。」），轉變成特定而可行動的定義。
建立你正要改進之處的參考點。
…
競爭式標竿的優點：
- 列出資訊架構特色表，把新的想法帶上檯面。
從廣泛的一般化描述（例如，「Amazon的模式不錯。」），轉變成特定而可行動的定義（例如，「Amazon的個人化特色對常去的用戶而言很不錯。」）。
挑戰深陷腦中的假設（例如，「我們應該像Fidelity那樣。」），避免因錯誤理由把錯誤特色複製過來。
以競爭者為準，建立當前的地位。建立參考點，以評估改進的效率。
』
希望能繼續看到這兩種方式的工具及實作，這個功能很不錯。
用戶
『這是網際網路的快轉式演化。』ㄚ琪從前面一段讀來，書中就給與一個註解，但是這個註解，並沒有在ㄚ琪的腦中起漣漪，所以只能保留這個文字紀錄以備查考了。
『用戶是最大的。』在任何經濟的產業中，沒有人敢反駁這個說法，對一個工人來說，老闆一樣是最大的。
所以要學會研究用戶人口很重要，書中列出一個參考資料，Joann Hackos跟Janice Redish著的 (Wiley)User and Task Analysis for Interface Design， 另外可用性專家Jakob Nielsen的網站
useit.com: Jakob Nielsen’s Website，也是值得拜訪的一個網站。
因為沒有一種單一的方法是正確的，所以『最好是採用五次面談和五次可用性測試，而不是同一測試跑十次。每一種做法都符合報酬遞減綠的法則。』看起來就是多讀資料，看看人家的經驗，並且運用在自己身上，那就是最好的了。
重點來了，『首先，奉行打折可用工程的黃金律：有測試比沒測試好。不要讓預算或時程變成藉口。其次，記住用戶是你最強而有力的盟友。…用戶研究是極為有效的政治工具。』
以客為尊真好。
使用量統計
『你的網站上之使用量統計資料是開始工作的合理地點。大部分統計資料軟體套件（像是Google Analytics） 會提供下列報告：
- 網頁資訊
- 訪客資訊
…用戶在網站中移動的路徑就稱為點閱路徑(Click Stream)。…』 但是用統計資料軟體很難有所作為，如果要有價值，『就是從用戶得來的回饋資料，讓他說明為什麼會來這個網站，他找到什麼，以及為什麼離開。』
後面說的才是重點，ㄚ琪以前也會這樣訪問訪客，不過這很耗時，而且多次的結果，訪客都表示他忘了，看起來即時的面談調查是很重要的，否則客戶不會記得當時的情境，另外有些客戶會對這樣的行為感到突兀，所以怎樣避免引起不悅的感覺也要注意。
搜尋日誌分析
『一個比較簡單但相當有價值的做法，就是去追蹤和分析搜尋引擎所取得的查詢內容。』
『當你在開發控制詞彙時，這是相當有用的資料。當你要把某些術語當成最佳猜測策略下，優先考量的術語時，它就相當有用。』
『搜尋日誌的分析，可以讓你對用戶真正在搜尋的東西有敏感度。』
顧客支援資料
參與者的定義和召募
『對大型專案而言，資訊建築師應該考慮與傳統市場研究公司合作，他們有界定觀眾類型的經驗，可以在這些觀眾類型之中找出各種參與者，召募參與者，後勤處理，像是設備、獎勵，以及紀錄。』
能夠做到這程度，花些錢找專家也無可厚非了。
問卷
『問卷(survey)是一種寬而淺的研究工具，提供一種機會，從一大群人那兒快速而廉價的取得輸入資料。…
除了用戶意見的價值之外，問卷也提供一個強而有力的政治工具。如果90%的用戶說員工名冊是最重要，但卻是最令人失望的企業網路資源，那就是必須予以改進的強迫性理由。』
好像每次提到人，就會跟政治扯上關係，唉。
情境式調查
『田野調查是各學科研究課題中相當重要的部份，從動物行為到人類學皆然。…』
田野調查(Field study)又譯為田野工作或實地考察，為對於描述原始資料蒐集的概括術語，其所應用的領域包括民俗學、考古學、生物學、生態學、環境科學、地質學、地形學、地球物理學、古生物學、人類學、語言學、哲學、建築學、及社會學等自然或社會科學領域。
真沒想到『這些情境式調查(contextual inquiry)方法對資訊建築師而言也有用。』不過應該是相當費時，課本也推薦，Hugh Beyer跟Karen Holtzblatt 寫的Contextual Design(Morgan Kaufmann)一書。
焦點小組
焦點小組（英文：Focus group），也稱焦點團體、焦點群眾，是質性研究的一種方法，就某一產品、服務、概念、廣告和設計，而通過詢問和面談的方式採訪一個群體以獲取其觀點和評價。該焦點小組的成員往往經過實驗者選擇而定，並保證在實驗過程中被試方能夠充分分享其意見和主張。
上述這一段維基的解釋，ㄚ琪就覺得很完整了，要應用在資訊架構學中，應該不難。不過這個工具，課本說明這是『測試網站可用性中相當弱勢的工具』，看起來是參考用用就行的樣子。
用戶研究會議
面談
整節讀來抓不出重點來，不過倒是有checklist可以用，ㄚ琪不列了。
卡片排序
『卡片排序時要考慮下列諸點，開放/封閉、措辭、粗細程度、異質性、交叉列出、隨機性、量化/質化。』
聽說有MindCanvas可以使用，不過上去看看支後肢有DEMO，玩起來也不覺得順，看來也是要收費的，所以作罷。
用戶測試
『用戶測試有很多別名，包括可用性工程和資訊需求分析。』
你可以考慮以下的路線來著手：『容易到不可能、已知項目到詳盡的、主題到任務、人工到真實。』
研究的保衛戰
『沒有時間作研究會怎麼樣？』這裡舉出一個案例，然後直指這個專案落入『死亡盤旋』，這還真可怕啊。
克服研究阻力
這裡頭常見的原因有：
『
- 我們沒有時間或沒有錢。
- 我們已經知道要什麼。
- 我們已經做了研究。
』
看到正中ㄚ琪的下懷的原因了，看來這應該是要改進的地方。
另外另一個重點，『害怕分析癱瘓(analysis paralysis)的危險，商業經理人傾向於行動導向。「讓我們跳過研究，開始做事吧」是相當常見的說法。』
這個問題其實換另外一種方式講，應該是經驗不足導致我們沒法子估計狀況，就無法事先去做研究，於是我們常會落入且戰且走的心態，沒有廣泛的認知情況及經驗確實是很危險的，今天好在ㄚ琪看了，所以可以更有深度的做這方面的工作。
今天其實也剛好碰到一個新進人員，突然要求改善他們的資料庫的欄位，但是這並不尋常，結果發現他並不瞭解情況，更無法決定這個欄位長度，只會問你的容量最大可以到哪裡，但是完全沒有使用的經驗值，這個結果終將導致系統的肥大及不適用，唉。
現在提出做研究的好處了：『
做研究可以節省時間和經費：習慣性跳過研究而進入設計是專案經理常犯的錯誤，他們看到效率假象，卻看不見真正的效率。』
這個剪圖可以清楚看出，如果你是先開工，找目標，那麼整個專案的時間會比先找目標，開工的時間要長。少了研究(Research)，其餘的策略(Strategy)、設計(Design)、實作(Implementation)的時間將加長。
另外的好處：
『經理不知道你們的用戶要什麼』：對啊，他們會很直覺用他想要什麼來跟你說，所以經理人的智慧就變得很重要了，成敗都在乎他。
『我們需要做資訊架構研究』：對啊，不然我花這麼多時間看這一篇，所為何來？Of course,why not?