用 prototype 避開局部最佳解
產品開發初期，通常使用者情境和需求都還不夠明朗，這種前提下進行的 prototype 測試最好把目的放在「透過 prototype 釐清問題」，才能避免只找到局部最佳解。
我在 Circuit Breaker 這集的 Podcast裡學到一個簡單可行的作法：在測試過程同時提供截然不同的數款 prototype 給使用者。當人們遇到有多個選項時，就可以比較明確的指出「這個比較好，那個比較不好，因為……」，讓我們不只得到使用者情境的情報，也同時釐清哪個設計提案有繼續發展的價值，提高命中全域最佳解的機率。
「意義在比較之中產生。」
如果使用者一次只面對一款 prototype 提案，就容易落入過度關注提案本身好壞的隧道視野， 我們沒有辦法透過訪談挖掘需求和情境的真實原貌。更糟的是如果不小心得到使用者的正面回饋，我們就很有可能基於這個 prototype 繼續發展下去。但沒經過發散再收斂的過程，通常就只會得到局部最佳解。
在讀完 David Rutten1 寫給設計師看的基因演算法介紹後，我發現這種 prototype 測試過程其實和基因演算法的邏輯蠻相似的；如果基因組之間差異性極小，那麼很快就會得到趨近於極值的結果，如果基因組之間有一定的變異性，就有非常多可能性。差就差在使用者情境往往是複雜多變、難以量化的，也就不太可能只靠基因演算法就找到解答。
Rhino內建視覺化程式語言 Grasshopper的主要開發者↩︎