用 prototype 避開局部最佳解

產品開發初期,通常使用者情境和需求都還不夠明朗,這種前提下進行的 prototype 測試最好把目的放在「透過 prototype 釐清問題」,才能避免只找到局部最佳解。

「意義在比較之中產生。」

我在 Circuit Breaker 這集的 Podcast 裡學到一個簡單可行的作法:在測試過程同時提供截然不同的數款 prototype 給使用者。當人們遇到有多個選項時,就可以比較明確的指出「這個比較好,那個比較不好,因為......」,讓我們不只得到使用者情境的情報,也同時釐清哪個設計提案有繼續發展的價值,提高命中全域最佳解的機率。

如果使用者一次只面對一款 prototype 提案,就容易落入過度關注提案本身好壞的隧道視野, 我們沒有辦法透過訪談挖掘需求和情境的真實原貌。更糟的是如果不小心得到使用者的正面回饋,我們就很有可能基於這個 prototype 繼續發展下去。但沒經過發散再收斂的過程,通常就只會得到局部最佳解。

在讀完 David Rutten1 寫給設計師看的基因演算法介紹後,我發現這種 prototype 測試過程其實和基因演算法的邏輯蠻相似的;如果基因組之間差異性極小,那麼很快就會得到趨近於極值的結果,如果基因組之間有一定的變異性,就有非常多可能性。差就差在使用者情境往往是複雜多變、難以量化的,也就不太可能只靠基因演算法就找到解答。

prototype-optimum.png


  1. Rhino 內建視覺化程式語言 Grasshopper 的主要開發者