《思考的演算》閱讀筆記：發現用戶體驗設計中的資訊架構技巧
最近閱讀《思考的演算》這本有趣但燒腦的書，它是探討計算思考的科普書籍，作者身分是兩位英國電腦科學教授，為了推廣電腦科學教育、人機互動所寫的書籍。
書中大多數的篇幅在探討如何用運用電腦的思考方式，來學習演算法邏輯，書中稱呼這個方式是「計算思考」。
此書兩位作者很會說故事，例如用撲克牌魔術、井字遊戲等通俗案例來解釋怎麼運用計算思考的邏輯，程式設計師可以怎麼推演出電腦可以判斷並處理情境的方法（就是演算法啦）。
演算法思考是解決問題的特殊方式，透過這種方式，你不會只想出單一答案，而是會想出一套可依照步驟順序而行的解決方案，讓其他人（包括電腦在內）都能遵循此步驟而得到答案。(中略)...這個過程聽起來有點緩慢，可能還有更好的方法--思考著更好、更有效的解決方法，也是演算法思考的一環。
本來我也只是看著看著，權當吸收演算法知識在看閒書的角度，但作者們不愧是人機互動的教授，在一些章節突然神來一筆，總是能扯到用戶體驗設計的領域（畢竟就是電腦跟人如何互動的設計領域嘛）。
例如下面這例子：
「取消」的表示法，對任何涉及人類的演算法來說都很重要，因為人就是會犯錯。在這邊摘錄幾個作者們在書中反覆提到的好觀念：
評估（evaluation）：只要想出一個新的演算法，就必須非常仔細地檢查它是否能成功運作。程式設計師花在評估程式的時間，比寫程式的時間還要多。很容易就會發現某個細節出錯了，或是忘記某個情況會三不五時出現，所以這個演算法也必須把解決的方式涵蓋其中。重點在於，這個演算法每一次都要能成功運作，無論發生什麼事都一樣。模式比對（pattern matching）：你眼前問題的本質，通常與你在不同情況下看過的問題一樣。因此，若你已為那問題想出了一個解決辦法，你就可以再使用它一次。通化（generalisation）：我們手邊有一個適用於許多不同問題的解決方法，為該演算法建立描述，當適合的情況出現，就能選擇此演算法來解決問題。抽象化（abstraction）：用以簡化問題，讓計算思考變得更容易，抽象化代表隱藏或忽略部分細節，好讓後續的事情更容易完成。拆解（decomposition）：將問題拆解成不同部分，讓我們能分別專注處理每一個小問題。拆解仰賴抽象化的技巧。
上述觀念換成我們在進行UX的資訊架構時，完全能套用上述技巧，例如：
資訊架構的評估
每增加一個新的服務情境，就要仔細檢查它跟其他情境是否衝突，會不會影響已經存在的流程？
資訊架構的模式比對
不同的用戶情境能不能歸納出相同的問題本質？能不能使用同一個流程解決產品其他流程的問題？好用來降低用戶的學習成本。
資訊架構的通化
我們手邊能否列出許多解決數位產品的基本解決方案？許多數位產品都採用過的設計方案雖然老套，但大多數人都養成習慣了。
資訊架構的抽象化
現實的服務情境有許多人類工作的細節以及變數，透過案例研究以及用戶訪談後，要再進行抽象化，只專注解決能被數位產品解決的問題與步驟。
資訊架構的拆解
將用戶的旅程地圖拆解成許多部分，挖掘 / 抽象化提出數位產品介入最適合的人機互動情境。
最後，我很喜歡作者在第二章的故事中，透過《潛水鐘與蝴蝶》這個真實故事，推論那名中風全身癱瘓只能透過左眼眨眼來表達意思的作家，如何發展出用最少的眨眼次數表達正確意思的過程。（例如在五個問題內得出任意字母的決策樹）。
作者在第二章最後說：
在演算法的評估上的另外一個重要面向：需要評估當我們的解決方案應用在人們身上時，是否能夠成功。人們能輕鬆使用這些方案而不犯錯嗎？他們在使用時的經驗好嗎？就算遵循演算法的是台電腦，如果之後有人得和這程式進行互動，也適用於這個面向。這被稱為可用性（usability）和使用者體驗（user experience）。這種評估最終必須在真人身上進行實驗。我們的實驗越早開始越好。（中略）...在設計任何牽涉到人的系統時，使用者中心的設計都是更好的。最終來說，是使用者要適應這些幫忙他們服務的工具，不僅是科技上的適應，也包括情緒層面以及社會層面上的適應。否則我們可能會設計出一套在理論上極為完美，實際上卻難用到要死的「解決方案」。
最近跟朋友剛好在討論該怎麼入門資訊架構，所以在寫這篇讀後心得時一直採用資訊架構來舉例，如果各位閱讀此篇的朋友也對於「資訊架構的入門」有興趣，還請您幫我多拍點手兒！
感謝您的鼓勵。
查看獸群之心的 UX 文章目錄
