高中的時候，有個留級的朋友問我，你會不會覺得唸這些東西一點用都沒有。書呆子的我，帶著疑惑問：「為什麼會這樣覺得？」但現在過了 15 年，我真的很想問那時候的我，為什麼不會這樣覺得。

1
2

工程和管理的訓練是解決問題，而設計師受的訓練是發現真正的問題。
--- from 設計的心理學 by Donald A. Norman

聽到「幫我買一顆蘋果」這個問題，工程師會這樣做。

1
2
3

工程師：花一小時，找出一大堆的購物網站，列出各種蘋果的價格和評價，然後請你挑最好的一個。

妹子：我只是想和你見個面聊個天，為什麼我必須要看那麼多資料... 而且還要我上網訂、見不到面，還是放棄治療好了。

聽到「幫我買一顆蘋果」這個問題，設計師會這樣做。(這邊設計師不含 VD)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

情況一：
問：你為什麼要買蘋果？
答: 因為想幫房間增加一點紅色。
問: 為什麼想幫房間增加一點紅色?
答: 因為想把房間變漂亮？
解: 設計師把房間的燈從冷色系換成暖色系。

情況二：
問：你為什麼要買蘋果？
答：因為我肚子餓。
問：可是你不是剛剛才吃完飯？
答：嗯，對喔。(OS: 我只是看你太閒，要給你一點事做。)

情況三：
問：你為什麼要買蘋果？
答：因為要吃。
問：你為什麼要吃？
答：我每天都要吃一顆，今天沒帶。你廢話那麼多要幹麻？(OS: 這個下屬理由很多。)

工程師和管理把問題往下展開。
設計師把問題往上展，如果找到更簡單的問題再往下展。

工程師：直接把問題往下展開：

1
2

優：能最快速找到這個問題的解法。
缺：你解決的可能根本不是重要的問題。

設計師：把問題往後回推，找新問題解

1
2

優：也許能找到真正需要解的問題、花更少的時間就能解決問題。
缺：別人會以為你不想理他在找藉口。老闆會以為你在故意質疑他。如果原來的問題本來就是對的問題，你只是在浪費時間。

理性與感性

1
2

「現階段的實際工作中，設計師們無論是在方案的設計還是方案的表達上，往往都顯得感性有餘、理性不足。」
--- by 汪方進 ＠ 阿里巴巴 1688用戶體驗部

一個設計師，不光只有同理心、邏輯推理能力、各種知識也很重要。沒有知識不能推理啊… 所以工程師們快和我一樣跳進來吧~~~ 當設計界的理性之光。其實就演算法的角度來看，就是兩種不同的方法，各有各的使用時機、各有各的風險報酬，如果要能解決生活中的問題，這兩個都很重要。所以也別分什麼工程、設計、商業，如果有需要就學吧。大學四年可以學一個專業，但人生有多少個四年啊… 是不是該多學幾個專業 XD

註： 把視覺設計師(VD)和程式設計師特別切出來的原因是：他們的工作都偏向在給定的問題中找解法、做的是實作中一定要做的事。但真正優秀的會去觀察使用者。(工程師的話推薦看：程序員的修煉、駭客與畫家，都有提到這點)

註：上面的對話都是我的想像舉例，別太認真。想知道真正答案的話，或是測試這個人的工程設計傾向，可以請他幫你買顆蘋果看看。

函數是有定義介面的運算單元。

介面有用的地方是抽象化，你只需要知道輸入什麼(Input)、會得到什麼輸出(Output)，你不用知道它細節是怎麼做到的。其實有個超能力在背後，也沒關係。當然這是在沒有碰到 bug 和有良好文件、不需要修改它的前提之下。

再強調一次，你只需要理解輸入(input)會對應到什麼輸出(output)就夠了。

問題來了，怎樣的輸入和輸出的對應「介面」會容易讓人理解？

• 有意義的函數名稱

• 多寫沒有副作用的純函數

  • 有可預測性：
    每次輸入得到相同的輸出、函數內部不存狀態
  • 沒有副作用：
    運算過程中不會改到外界的變數，像是不改傳進來的參數、不改可以存取的全域變數。
  • 顯式(Explict)：
    函數和外界溝通的管道只有，傳進來的參數和回傳值。

• 簡化參數、對資料結構的 Information Architecture 做良好設計

• 用函數來定義函數

  • 柯里化(Currying)：
    透過不同給參數來產生新的函數
  • 合成(Compose)：
    透過 pipeline 串接函數的input和output、隱藏參數，產生新的函數。

函數式編程為什麼強大、有彈性？

• 把每個函數切得很小，容易更新、維護、平行處理、多人共同開發、被理解

• 透過合成(Compose)把小函數變成大函數，比用繼承有彈性的多

• 對集合實做 Functor 介面，讓一般函數都可以對集合操作。(array, matrix, tensor)

• 把純和不純的函數分開來管理，容易找到問題點。

函數式編程為什麼難寫？

因為函數式編程想要把程式變簡單。但大家都知道「變複雜是簡單的、變簡單是複雜的」。所以這種方式寫程式需要設計、思考，你會是一個程式「設計師」。但如果你現在的專案寫完之後沒人會看、不會再改、不用維護、規模不大，也許函數式編程並不能幫到這個專案多少。

寫 React 就是實踐函數式編程

• 透過自定義元件，定義畫 View 的抽象化函數樹

• 透過 JSX 語法把小函數組合成大的函數 (等同於 compose)

• 鼓勵大家寫 dumb 元件、也就是純函數

• 用唯讀的 props，限制大家不能改傳進來的參數、減少副作用

• 透過導入 flux，把純和不純的函數分開來管理

  • 純的 (對資料只做讀的動作)：每個元件中的 render function
  • 不純的 (對資料做讀和寫的動作)：
    flux中對 action 的 callback、redux 中的 reducer、父元件傳給子元件的 callback
  • glue code：元件中其他的 javascript
    

從函數式編程的角度看 React 的問題？

• 沒有什麼高階的集合操作方法：

  • 把 lodash.js 集合操作拉進來用？
  • 用 lenses 的方式來穿透深長不露的 states?

• 沒有簡單的 currying 語法

  • 像是傳不同參數給 html5 input 元件，生出各式各樣對數字的、email、submit、text的自定義元件。最簡單寫法應該是
  • export function NumberInput(props) { 角括弧input type=“number” {…props} /> }
  • PS: function 一定要有名字不然 debug 會很慘。

• 雖然集中管理了不純的函數，但還是很難寫：現在透過修改 store 中的 state 來控制元件，這邊 action 觸發的都是不純的函數，如果元件架構一深，還是會很難改。有解嗎？這邊還沒找到什麼 coding guideline…

  • 多個 container smart 元件
  • flux 的多個 store
  • redux 的階層式 reducers

延伸閱讀：
deku: functional alternative to react
how to use classes and sleep at night (in a functional way)

Curried Function：到拿到所有需要的參數前… 一直回傳新函數的函數。

1 2 3 4 5 6 7 8 9 10

var add = function(x) { return function(y) { return x + y; } } var add3 = add(3); add3(4); //return 7 add(3)(4); //weird thing

autoCurry in Wu.js will save us

1 2 3 4 5 6 7 8

var add = function(x, y) { return x + y; }.autoCurry(); var add3 = add(3); add3(4) //7 add(3,5) //8 => not weird any more!!!

但我們為什麼需要 curry？參考下面這個組成新 function getTheOdds 的例子。 有了currying，我們可以透過給予不同參數來建立新的函數。

1 2 3 4 5 6 7 8

var filter = function(f, xs) { return xs.filter(f); } filter(isOdd, [1,2,3,4,5]) // [1,3,5] var getTheOdds = filter(isOdd); getTheOdds([1,2,3,4,5]) //[1,3,5]

再來一個用loadash的酷例子

1 2 3 4 5 6 7 8 9 10 11 12

//沒用currying、不函數化的寫法 var firstTwoLetters = function(words){ return _.map(words, function(word){ return _.first(word, 2); }); } //函數化的寫法(如果underscore吃參數的方式是反過來的話) var firstTwoLetters = _.map(_.first(2)); //更函數化的寫法 _.map(_.first(2), ['jim', 'kate']) //['ji', 'ka']

=> Underscore.js的參數排列法讓currying變得不可能 總結currying的優點有下面四個：
* 一般化函數、要傳的變數名消失了
* 透過給不同參數就可以生成不同的函數
* 更簡潔的定義
* 讓函式的組合/合成 (composition) 變的可能

組合/合成 (composition):用多個函數來組成新函數 簡單的例子，用 first() 和 reverse() 來合成 last 函數

1 2 3 4 5 6 7 8

var last = function(xs) { var sx = reverse(xs); return first(sx); } var last = compose(first, reverse); last([1,2,3]) //3

另一個例子，chain backwardly

1 2 3 4 5 6 7

var wordCount = function(str){ var words = split(' ', str); return length(words); } var wordCount = compose(length, split(' ')); wordCount("There is a way to save the world") //8

Category Theory: 多個函數組合(compose)，作用域互相對應的理論。Connecting the dot. 總結組合：
* 能從其他函數組成新函數
* 組合過程中把參數藏起來
* 極為高階的寫程式
* 有數學理論在後面支持

Functors map 打開了後面的 object 然後做一些事、再放回 object

1
2
3
4
5

var plus1 = function(x){ return x + 1 }

plus1([3]) //wrong!!

map(plus1, [3]) //4

剛剛舉的例子，map 只能操作 array object、但下面試圖用 map 操作所有 object

1
2
3
4
5
6
7
8
9

map(plus1, MyObject(3)) //MyObject(4)

MyObject = function(val) {
  this.val = val;
}

MyObject.prototype.map = function(f) {
  return MyObject(f(this.val));
}

如果對 object 定義了 map function，它就變成 functor null check的例子、Dynamic Safety：

1
2
3
4
5
6
7
8
9
10
11

map(plus1, Maybe(3)) //=> Maybe(4)

map(plus1, Maybe(null)) //=> Maybe(null)

Maybe = function(val) {
  this.val = val;
}

Maybe.prototype.map = function(f){
  return this.val ? Maybe(f(this.val)) : Maybe(null);
}

把 ES6 promise 變 functor 的例子

1
2
3
4
5
6
7
8
9

map(populateTable, $.ajax.get('/posts');

Promise.prototype.map = function(f) {
  var promise = new Promise();
  this.then(function(response){
    promise.resolve(f(response));
  });
  return promise;
}

再來一個和 html 合作的例子：對有和沒有 user_login 的情況下，更新歡迎頁面。

1
2
3
4
5
6
7
8

$div = $("#myDiv");

//dot 會把 user.name 拿出來
var getGreeting = compose(concat('Welcome '), dot('name'));

var updateGreetingHtml = compose($div.html, getGreeting);

map(updateGreetingHtml, Maybe(App.current_user));

underscore 不讓人 extend map 總結 functor 能:

• 改變函數的行為卻不用變動 open/closed principle
• 不光只有 map, 還有 reduce & compose *
  直覺且非私人的 api
• free formulas
• 動態型別安全/檢查

總結：underscore 能變得更加 functional。希望有更 functional 的 library

組合虛擬人物 （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、強大的設計師 美辰、很有主見的獸醫系 元皓、講話有趣的東璋、眼鏡很帥的財金系 軒凱、討厭心智圖但會組織演講的柏儒，這次有點忘記一期一會的決心…