The Intersection 交會點
二○○七年在Macworld上，賈伯斯在演講進入第四十一分鐘左右時，開始介紹iPhone。他切換到下一張投影片，上面是一個黑色的蘋果商標遮住太陽的圖，接著他說：「我從兩年半前，就一直期盼這一天的到來。每隔一段時間，就有一款革命性的產品誕生，改變一切。」
當天，我坐在觀眾席上。在此之前，Purple團隊的每個人為了這場重大的發表會，抱著使命必達的決心，始終傾注全力。雖然我為此刻感到興奮，但我其實不太確定我要怎麼解讀賈伯斯的那番話。那一刻，他對iPhone 的前景深信不疑，但我對它只抱著希望。
過去一年半的時間，我一直把Purple視為原型機，而非產品。通常我只關注那些運作不太順的部分，我把焦點放在開發功能、除錯、進一步改進、為新的演示做準備上。在產品開發的過程中，很難維持更廣大的視角，因為你必須確保每次演示的意見與回應最後都促成進一步的累積。
本章標題中的「交會」是很實用的概念，它說明了蘋果對科技與人文藝術專業的同等重視。我們開發及朝夕體驗產品時，以這個概念來指引我們，好讓產品不只是最新的中央處理器（CPU）、感應器、大規模軟體的合成品而已。我們希望蘋果的產品對消費者來說是有意義且實用的。
不像創意競擇是一種只這麼做、不這麼說的概念，我們在蘋果確實常把「在科技與人文藝術的交會點運作」掛在嘴邊。蘋果大學（Apple University）裡甚至還有一門課程談這個主題：這是一場半天的討論課程，內容探討科技與人文藝術的融合、為什麼在科技與人文的交會點很難運作，以及堅守這個原則的重要性，因為這正是蘋果開發卓越產品的核心理念。
我們不僅在公司裡自由討論這個「交會」概念，怪的是，這種討論不止限於蘋果的總部內，賈伯斯在產品發表會上宣布第一代iPad時，也親自跟大家分享了他對這個主題的看法：
蘋果之所以有能力開發出像iPad 這樣的產品，是因為我們一直努力站在科技與人文藝術的交會點，希望能兼顧這兩個領域的精華，不僅開發出最先進的科技產品，也把產品設計得直覺好用又有趣，以便眞正適合消費者。消費者不必屈就產品，而是產品來迎合消費者。
在科技和人文藝術的交會點運作─這個概念可追溯到蘋果早期的歷史。賈伯斯以這點來解釋一九八四年推出的第一代麥金塔電腦為什麼使用比例字體，而不是當時一般電腦使用電傳打字機那樣的等寬字體。從那時起，「在科技與人文藝術的交會點運作」變成蘋果渴望在產品中挹注的特質總和。它超越了字體、顏色，以及當你聽到人文藝術中的「藝術」那個詞時，可能想到的視覺設計元素。
這種努力也延伸到五感上。我希望iPhone 的鍵盤點擊能喚起打字機的按鍵敲擊頁面的咑咑聲，最後我是以鉛筆敲打辦公桌的桌緣來模擬這個音效。我的靈感是來自一個故事：第一部《星際大戰》電影的音效師班．伯特（Ben Burtt）為了呈現爆能槍掃射的音效，他去錄下鐵鎚敲打天線塔鋼索的聲音。
在「在科技與人文藝術的交會點運作」不只是持續精進細節，使每個圖示、動畫或聲音盡可能達到美學理想而已。人文藝術元素與先進科技必須結合起來，而且最終只能看產品與人的契合度來做整體判斷。
以下三個小故事說明了我們在整個iPhone開發過程中是如何做到這點的。這些故事說明了iPhone軟體的一些功能與屬性是如何形成的，並以實例解說我們在科技與人文藝術的交會點如何運作。
第一個iPhone 遊戲非常有趣
二○○五年夏季我加入iPhone開發團隊時，對觸控螢幕軟體一無所知。拿到第一支小袋鼠後，我編寫程式，把小袋鼠接上Mac電腦，接著看到app的圖形顯現在原型觸控螢幕上─那是一種很新奇的體驗。我把雙手從Mac電腦的鍵盤移開，拿起小袋鼠，接著點擊app圖示，在滾動淸單中挑選不同行列，在app之間切換。當時Purple隊友都在做同樣的事：測試用手指與小袋鼠上的軟體和圖像互動是什麼感覺。
軟體團隊的每個人都忙著解決自己負責的技術問題，忙著開發郵件、Safari、備忘錄、SpringBoard等app。不久，我們開始問彼此一個同樣的「大」問題：在那個小螢幕上，每個物件要設計成多大，才容易點擊？那個點擊目標必須夠小，螢幕才能展現出夠多實用的內容。那個點擊目標也必須夠大，這樣才容易點擊。但除此之外，我們對螢幕上的物件大小並沒有更多詳細的概念。
SpringBoard是用來展示手機主畫面的程式。對SpringBoard來說，拿捏主畫面上物件的尺寸特別重要。主畫面上的方形圖示代表手機上的app，按下一個圖示就會開啟一個app，並占據整個螢幕。點擊正確圖示的感覺是愉悅的，因為手機會按你的指示打開備忘錄、瀏覽器或行事曆。在任務之間切換的速度，跟思緒轉換的速度一樣。按錯圖示則令人焦躁，就好像你伸手拿餐具想要喝湯，把餐具伸入湯中，才發現你拿到叉子，而不是湯匙。
對SpringBoard來說，工程師把這種人體工學問題簡化成：為主畫面上的每個圖示找到最適合點擊的尺寸。我們也不知道合適的尺寸應該是怎樣。最初幾次拿小袋鼠做演示的經驗，讓我們了解一般大眾在身體結構與手指靈巧度上可能介於哪個範圍。
史考特的手指細長，指尖很小。他可以把大拇指放在小袋鼠的螢幕上方，然後像機器一樣精準地上下移動，就像引擎氣門裡的搖桿一樣。他先天就能以出奇精準的方式，點擊觸控螢幕上的東西。他可以不加思索地點中螢幕上最小的使用介面元素。
相反的，葛瑞的手會抖。如果他才剛去室外抽菸回來，他的手指抖得特別厲害。如果軟體開發團隊的人提供給葛瑞點擊的圖示太小，他還是會試用，但點擊失敗時，他總是大嘆一口氣（典型的紐約客長嘆），以表達他根本無法用你這個東西的不爽心情。葛瑞這樣做其實很合理。切記，賈伯斯可沒說產品應該跟消費者作對，他說產品應該「迎合消費者」。
我們預期一般大眾的差距會比史考特與葛瑞之間的差距還大，但是他們不同的用戶體驗在產品開發早期讓我們確定了一點。iPhone最重要的用戶互動之一，取決於一個問題：主螢幕的圖示要多大才恰當？
Purple夥伴史考特．赫茲很快就為我們找到了答案。他寫了一個程式，並傳給Purple團隊使用。那個程式沒有很多功能，啟動時會出現一個很大的開始鈕。按下按鈕後，螢幕會先空白一會兒，接著出現一個方框。我們的任務是點擊那個方框。你點擊後，無論你的點擊是否精準，螢幕會先空白一會兒，接著另一個方框又出現在其他地方。只不過這次的方框尺寸不同，可能更大，也可能更小。你需要陸續點擊螢幕上出現的方框。
其實，這個程式很有趣，像玩遊戲一樣。連續點擊約二十次方框後，這個「遊戲」就結束了，程式會顯示你的得分：你點中幾個方框，錯失幾個方框。軟體在幕後追蹤每個方框的尺寸及位置。這個測試程式可收集必要的觸控螢幕可用性資料，很快就傳遍了Purple團隊。幾天內，我們就收集到許多圖示尺寸及點擊精確度的相關資訊。
這個程式的結果顯示，如果方框的大小是57 x 57畫素，我們可以把它放在任何地方。那樣做的話，每個人都可以輕易點中方框，精確度接近100%。這個程式為我們的問題找到了答案。第一代iPhone主螢幕上的圖示尺寸就是57 x 57畫素。
順暢
iPhone 使用介面有一個關鍵的大概念直接操作（direct manipulation）。這個概念是指，把一些實體物件的屬性與行為加諸在軟體物件上，讓使用者操作這些數位物件時，彷彿跟現實世界的東西互動一樣。
舉例來說，想像你坐在一間辦公室裡，桌上擺了兩個物件：一張紙和一個資料夾。如果你想把那張紙放進資料夾中，你可以伸手拿起那張紙，把它放進資料夾，或許你會稍微把資料夾打開一點，讓過程更順暢。直接操作實物，可以持續獲得感官回饋（視覺、觸覺、聽覺上的回饋），那些感官回饋可以幫你追蹤流程。
然而，在整個電算史中，執行這種單調的行為，從來不是一件容易的事。幾十年來，用戶若要與數位物件互動，一定要對電腦輸入文字指令。這種概念隔閡增加了操作難度。在安裝UNIX系統的電腦上，把文件移到資料夾的指令是：
mv paper.txt folder
為了發出這個指令，你必須知道「move」（縮寫成mv）程式的名稱，並記住先輸入你要移動的物件，再輸入移動的目的地。對一般人來說，這種程式互動方式使電腦顯得很抽象、疏遠、不直覺。只有技客覺得學習這些神祕語言很酷，其他人只覺得電腦難以親近。
一九八○年代，蘋果以麥金塔電腦改變了這點。麥金塔的圖形使用介面，以及滑鼠與圖示，提供用戶更直覺的體驗。想與某個物件互動，只要把滑鼠游標移到那個物件上就行了。點一下圖示先選取物件，接著按住滑鼠就可以移動物件。這個手勢讓人聯想到用手抓住物件。把物件放入資料夾，就是把物件圖示移到資料夾圖示的上方，然後放開滑鼠按鈕。這些設計使電腦操作變得更簡單，有助於導入直接操作的概念：你可以在螢幕上看到可互動的物件圖示並用滑鼠點擊。
直接操作不是蘋果發明的，而是一九八二年由電腦專家班．史耐德曼（Ben Shneiderman）發明的。但麥金塔電腦很快普及了這個功能。蘋果很早就知道這個頂尖的人機界面研究，派人去了解其核心技術概念，並以它為基礎來開發系統。而且，一九八四年一月開始，蘋果把這個技術綁在消費者購買的產品中。麥金塔電腦與滑鼠的出現，建立了蘋果「運用新科技來解決老問題」的傳統。這個方法也成為未來產品開發的靈感來源。
早在Purple 專案開始以前，蘋果就有一些設計師和工程師認為，使用手指操控的多點觸控軟體跟滑鼠一樣有潛力。他們認為，觸摸可以把電腦的互動模式提升到更直接的水準。他們希望多點觸控最後能完全取代我們對滑鼠的需求。看到螢幕上的圖示了嗎？你只需要伸手去觸碰就能操作。
伊姆蘭．喬德里（Imran Chaudhri）是多點觸控技術的早期支持者。他協助提供設計靈感，把這個新技術轉化為產品。
蘋果的軟體設計團隊以「人機界面」團隊自居是有原因的。人類才是核心，伊姆蘭跟我見過的所有人一樣，堅信產品應該為人服務。他就像蘋果內部許多有影響力的人，作品淸楚展現其個性。他有一種難以言喩的溫和、低調風格，但你跟他實際互動時，可以馬上感覺到他的特質。多年來，我常跟妻子提起伊姆蘭，後來她終於有機會在蘋果慶祝軟體發布的派對上見到他。派對結束後，她吿訴我：「我現在明白你對伊姆蘭的形容了，他確實充滿魅力。」
沒錯，伊姆蘭確實有魅力。不過，他跟蘋果歷史上最有魅力的賈伯斯不同，他從來不會激怒或斥責別人，講起話來總是很溫和。他的溫和有禮讓你不自覺地與他親近，輕柔的聲音讓人自然而然地專心聆聽，他的溫和與羞澀無關。事實上，他總是確切知道自己想要什麼。他針對我們正在開發的產品提到設計目標時，總是表達淸晰。
從Purple專案啟動開始，伊姆蘭對於多點觸控介面該如何運作，已經有一套想法。為了向一群Purple軟體工程師及設計師說明他的構想，他在前方的桌面上騰出一個平面空間，鋪上一張紙，然後伸出食指去觸碰那張紙的中間。接著，他開始同步移動手指與紙張，彷彿手指與紙張是不可分割的東西。他以手指壓住那張紙，把紙張移來移去。他的手勢與操作物件的同步移動，模擬了他希望iPhone 介面展現的流暢度與靈敏度。
「各位，」他以溫和的語調說，同時稍微點頭，讓大家把注意力集中在他的演示上，「系統應該像這樣運作。」伊姆蘭以這張紙在手指下滑動的方式，來顯示iPhone 直接操作該有的感覺。對他來說，操作的感覺非常重要。他認為iPhone 螢幕上的圖示應該黏在指尖上，就好像你拿起眞實物件一樣。他想說服大家相信，螢幕上數位物件的移動是實際施力的結果，就像食指黏住紙張。由於那張紙移動時不會暫停，也不會卡卡的，他認為像素的運作也應該要很流暢。
提供這種感覺是有目的的。伊姆蘭希望你把網頁往下拉以瀏覽網頁內容時，可以專注在內容上；與朋友一起翻閱度假相簿時，可以與朋友培養關係；滑動歌單、為當下挑選合適的歌曲時，可以想想自己當下的情緒或心境。他認為，如果螢幕上的圖像一直停留在指尖下方，你會忘掉科技的存在，沉浸在手機帶給你的體驗中。
減輕負荷
來做個小測試，仔細閱讀以下的指示，從中挑一個問題來挑戰，不要寫下任何東西，把答案記在腦子裡。先挑一個你最喜歡的問題吧！
1. 列出《白雪公主與七個小矮人》中那七個小矮人的名字。
2. 大於10的前七個質數。
3. 以母音開頭的七個歐洲國家的名字。
你的挑戰結果如何？如果你是迪士尼迷，第一題可能很簡單。又或者，你是數學天才或地理專家。即使你眞的是專家，也眞的沒寫下任何東西，但我敢說，你剛剛一定動用手指來計數了。如果你忍不住動用手指，那有點投機取巧，但我不怪你。在腦中一次要記住那麼多東西時，我們都需要一點輔助。
這個小測試說明了我在書中提過幾次的概念：心智負荷。我們的工作記憶有限，數十年來一直有人研究我們認知能力的極限，最早可遠溯及哈佛大學的喬治．米勒（George A. Miller）於一九五六年發表的心理學論文《神奇的數字7±2：我們資訊處理能力上的侷限》（The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information）。米勒想量化人類短期記憶的限制。他發現我們一次只能在工作記憶中保留約七個項目，就這麼多而已。如果想在腦中同時處理七件以上的東西，就需要開始分組，或者，如米勒所說的，開始「分門別類」。例如，我可以輕鬆按順序記住底下七種顏色：紅、白、藍、靑、黃、紫紅、黑色，因為前三種是美國國旗的顏色，後四種常用於平版印刷。因為我是美國籍，又有印刷方面的知識，我可以輕易把它們分組。即使是隨機的資料，要記住984-313-552也比847620475來得容易，只因為前面的數字多了破折號隔開，產生視覺的分組效果。然而，遇到大量資訊湧現時，如果不靠分組以騰出腦中的記憶空間，大腦就會超出負荷。一旦工作記憶被塡滿，就會開始頻頻出錯，判斷也會變得不太精準，運作能力迅速下滑。
開發產品的經驗讓我知道，這種限制是眞實存在的：與科技互動的時候，科技會像前面的小測試那樣造成心智負荷，尤其是全新科技或棘手的技術。我們很容易遇到心智界限，在複雜的情境中游移時，大腦很容易超出負荷，偏離正軌。我們很容易在眾多軟體功能中迷失，遇到那種情況時，我們通常欠缺足夠的知識，找不到扎實的立足點，無法專注在我們實際想做的事情上。
為了讓產品更平易近人，設計者必須降低用戶使用產品時的心智負荷。即便是微小的簡化，也可能有很大的影響。幸好，我認為幾乎所有的任務都可能改得更流暢簡潔，以減輕使用者的負擔。例如，我們回頭看前面的小測試，把它修改一下，讓它更容易完成。拿一張紙來，從底下三個修改後的問題挑一個，並寫下答案。
1. 寫出七個迪士尼角色的名字。
2. 寫出前七個質數。
3. 寫出七個歐洲國家的名字。
當然，這些問題比較簡單，但現實狀況不總是像這種人為設計的小測驗那麼容易簡化。在眞實的產品開發流程中，也有類似的簡化可能性。在蘋果，我們一直在尋找這種可能性。第一章的故事就是一例。我向賈伯斯演示iPad鍵盤的兩種方案時（一種是巴斯設計的多鍵方案，另一種是我設計的大鍵方案），賈伯斯認為我們可以消除選擇，減少iPad用戶輸入文字時的考量，讓產品更容易使用。這種機會不見得都很容易看到，拋棄系統的哪個部分可以促成「少即是多」的效果，不見得總是顯而易見。
在第一代iPhone的鍵盤開發後期，我不斷地調整及精進文字輸入軟體。隨著Macworld大會的逼近，我以為我們已經不再對系統做大改動了。然而，十一月，距離賈伯斯登台宣布iPhone僅剩約六週的時間，史考特要我刪除鍵盤上方的建議欄，那裡顯示三四個可點選的提示字，是自動校正系統認為你可能想輸入的字。
（p.278圖，圖說：第一代iPhone 推出時，我們移除鍵盤上方的建議欄。
此後，自動校正只出現在帶有插入點的單字正下方。）
建議欄是「參賽鍵盤」留下來的設計，史考特認為我們不需要這個功能。在型態偏移演算法及詞庫改善的協助下，自動校正系統運作得愈來愈好，系統建議的首選字幾乎都是用戶想輸入的那個字，系統會直接在你輸入文字的下方顯示首選詞。史考特思考了一個人輸入文字時可能注意的幾個地方：閃爍的插入符是其一，注意手指按在哪裡是其二。如果還要關注建議欄，那就太多了。建議欄增加了鍵盤系統帶來的心智負荷，就像上面的小測試在列舉歐洲國家的名稱之外，又多加了母音開頭的限制。史考特認為建議欄沒多大的輔助效果，反而令人分心，所以他要求我移除那個欄位。
這個決定使用戶輸入時，不再有持續閃著更新單字的建議欄，並騰出空間顯示更多的內容。而且出人意料的是，移除建議欄後，使用者測試顯示，使用者的輸入速度提升了，那提升幅度看似不大，但有統計顯著性。建議欄對大腦來說是額外的負擔，暫停下來看建議欄有沒有我們想輸入的字，比持續輸入並讓自動校正系統來代勞還慢。所以，在史考特的要求下，我們把設計簡化。
史考特要求我刪除建議欄這個功能時，我毫無不滿，雖然我為這個功能辛苦開發了一年多。身為蘋果產品的開發者，我們總是很樂於減輕軟體負荷，以提升用戶體驗。
以上三個故事體現了「在科技與人文藝術的交會點運作」是怎麼回事，它們顯示在科技與人文藝術之間拿捏平衡有多重要。赫茲找到了讓人輕鬆點擊圖示的尺寸；伊姆蘭希望用戶界面運作順暢，因為那種設計讓人把螢幕上的畫素和現實世界的體驗聯想在一起；史考特要求我刪除鍵盤上的建議欄，以減輕使用者的心智負荷。
決定輕鬆度、追求流暢性、降低心智負荷是我們在人體工學、觀感、心理效應方面追求的目標實例。在這三個例子中，精進及調整科技變成達致人本結果的方法。還有很多例子可以顯示我們為了融合科技與人文藝術所做的努力，但囿於本書篇幅，我無法在此全數收錄，所以底下只簡要列舉幾個開發Purple 的實例。
1.彎曲：你點擊iPhone螢幕時，可能以為觸摸到螢幕的是指尖，但事實不然。由於指尖有弧度，觸擊點其實比較低，那個比較低的點才是指尖最先觸及觸控螢幕的地方。軟體會修改你的實際觸碰點的幾何形狀，把它往上移或向上彎曲（warp），以解決這種差異，讓你感覺你的觸擊很準。
2.放大按鍵感應區：螢幕頂端方向欄位的返回鍵（back）實在太小了，用戶無法輕易點中，所以我們把那個按鍵的感應區放大（charged），也就是說軟體感應點擊的區域，比按鍵呈現的視覺區域還大。
3.易如反掌：原始的「滑動解鎖」功能是為了防止手機放在口袋或包包時，無意間啟動某個功能。滑動槽的介面設計很直覺，所以伊姆蘭第一次把iPhone 遞給三歲女兒時，她看了螢幕一會兒，在毫無提示下，就滑動那個控制槽解鎖了，輕而易舉。
4.按了一定有反應：在鍵盤區點擊，一定會啟動按鍵。由於按鍵在視覺上或軟體中都是分開、有間隔的，在鍵盤區內點擊，有可能沒點中任何鍵。但我認為，輸入者敲鍵盤就是想要輸入文字，系統一定要有反應才行。所以遇到沒點中按鍵的情況，我會啟動最接近點擊點的按鍵。
諸如此類的實例不勝枚舉，例如：實體的Home鍵還有一個令人安心的次要功能：使用者在app中迷失或困惑不解時，隨時可按Home鍵回到主畫面；動畫如何傳達app的運作模式─啟動與暫停放大和縮小功能、左右滑動以深入了解app的內容。
事實上，我可以沒完沒了地寫下去。如果你願意讀法律術語，你也可以。我推薦大家參閱美國專利第7,479,949號。面對蘋果的律師時，他們有時稱之為「949號專利」，一般人稱之為「iPhone 專利」。它的正式標題是「應用捷思以定義命令的觸控螢幕裝置、方法、圖形使用介面」（Touch Screen Device, Method, and Graphical User Interface for Defining Command by Apply Heuristic）。那份檔案是蘋果針對第一代iPhone 上的全新軟體特色及功能所做的官方聲明。
這份專利文件長達三五八頁，裡面充滿圖表、實例、聲明。這份專利申請的目的，是為多點觸控介面提供詳盡的說明，裡面有幾個單元深入探究許多互動功能的細節。例如，下面摘錄的文字說明在某些情況下，系統如何解讀觸控螢幕上的手指移動：
在某些實施例（embodiment）中，平移的方向直接對應手指移動的方向；然而，在另一些實施例中，平移的方向是根據規則，從手指移動方向映射而來的。例如，那個規則可能規定，如果手指移動的方向與標準軸的夾角在Y度內，那麼平移的方向是沿著標準軸。不然的話，平移的方向與手指運動的方向大致上是相同的。
怪的是，這些iPhone 的法律描述不知怎地，無法傳達Purple開發團隊費盡千辛萬苦想要融入iPhone的美好感受。當然，專利不是寫來取悅大家的。然而，949專利確實在最高層級提到在科技與人文藝術的交會點運作的一個根本要素。在那個專利檔案的標題中，它提到了蘋果的構成要素之一：捷思（heuristics）。
我們以「捷思」來形容軟體開發過程中偏向人文藝術的面向。與它對應的是「演算法」，演算法是偏向科技的面向。「捷思」和「演算法」就像同一枚硬幣的正反兩面，二者都是讓軟體去做它該做的事的具體程序：接受輸入、執行作業、產生輸出。然而，它們各自有不同的目的。
演算法產生量化的結果，衡量進展是看專案朝預定的方向進展多少，例如我們花了近一年的時間改進Safari 的績效。網頁載入測試（PLT）顯示程式碼執行的效率，並以一個數字（載入一個網頁的平均時間）來顯示測試結果。自始至終，我們都有一個明確的目標：降低這個數字。這個目標從來不是問題，速度當然是愈快愈好。改進文字處理器的插入點移動也是同樣的道理。閃爍的插入符號放在一行中間的英文單字末尾時，按一次空白鍵會插入一個空格，並把插入點向右移動一個字元。這種規定的對錯是沒有爭議的。如果按一下空白鍵沒有插入空格並使插入點前進，這就是錯誤。演算法就是這樣，它們是客觀的。
捷思也有相關的衡量或數値（動畫的持續時間或螢幕顏色的RGB値），但沒有類似的「改進箭頭」總是指著相同的方向。與評估演算法不同的是，捷思比較難確定。例如，你滑動螢幕後，網頁滾動應以多快的速度停下來？我們總是以演示的方式來評估可能性。我常與巴斯或伊姆蘭等人機界面的設計師坐下來，為手勢與動畫做出初步的決定，然後我們會讓更大的團隊來評審我們的初步選擇，接著整個團隊會朝夕體驗那個決定一段時間。我們運用同樣的方法來為整個系統開發捷思。
點擊一個app 後，它從啟動到塡滿整個螢幕，需要多少時間？手指在螢幕上要移動多長，系統才會把你的動作解讀成「滑動」手勢？使用照片app 時，對著一張照片執行兩隻手指抓放照片的手勢時，應該把照片放大幾倍？這些問題的答案都是數字：開啟app 的速度可能需要0.35 秒；滑動手勢可能是30 畫素；照片可放大四倍。然而，數字從來不是重點所在。從任何工程意義來說，這些價値本身並沒有明顯變得更好。數字代表合理的預設値、或令人滿意的效果，或只是讓人知道它們的意思，而不是它們的效用。想眞正了解這些東西的意義，需要花心思，這樣做其實很恰當，因為heuristic的字根是eureka，這個字是源自希臘語（不令人意外），意思是「尋找」。eureka這個字和我們開發流程之間的關係就是從這裡開始的，因為好的捷思不會突然閃現，是耐心探究後才有可能遇到。而且，即使我們找到正確的捷思，我們也不見得知道。我們只靠判斷力與時間做出最後的決定。捷思就是這樣，它是主觀的。
我們同時運用演算法與捷思，彷彿它們是集體產品開發的左腦和右腦。運用這兩個方法都涉及技藝與品味之間的交互作用，我們總是想要拿捏恰當的平衡。演算法與捷思必須協調，才能製造出卓越的高科技產品。迅速載入網頁、正確的插入點移動、高效率的程式碼、可愛的動畫、直覺的手勢、深思熟慮的內建行為等等，都是iPhone這種產品必要的。我們的目標是開發簡單好用的科技以及電腦輔助的人文藝術，同時結合兩者。
不過，在特定情況下，你必須正確判斷那個場合究竟應該使用演算法、還是捷思。這是Google測試四十一種藍色色調令我費解的原因，我已經習慣了蘋果的做法。Google使用A/B測試來挑選顏色，它使用單一的預定値標準，並把那個標準定義成「測試中，大家最常點擊的藍色就是最好的藍色」。這是一種演算法。在蘋果，我們從來沒想過用演算法來判斷正確的顏色。我們是用演示來挑選顏色及決定動畫時間，我們相信自己的品味。當我們去找「根據規則的手指移動」怎樣才算合適時（如我從949專利摘錄的內容所述），我們是做主觀的判斷，採用捷思。
與此同時，我們對於每件事都不會太偏向感性。打造最適的演算法，仍是為iPhone 開發軟體的重要部分，就像之前開發Safari 那樣。重要的是，演算法與捷思之間仍保有拉扯及交流的關係─究竟要偏向科技，還是偏向人文藝術，正確的選擇可能非常複雜。
例如，有時我們運用捷思來調和演算法。在鍵盤的自動校正功能中，型態偏移演算法總是可以為任何字母排列找到最近似的詞庫單字。試想，有人輸入oooorr，他可能只是想強調他在兩個美好選項中必須二選一，所以想強調or（或）那個字。（例如，選擇三球冰淇淋聖代或∼巧克力七層蛋糕做為餐後甜點）。但無論是什麼情況，oooorr這個單字都不在詞庫裡，而且根據鍵盤演算法，這個字看起來也不像幾何意義上最接近的詞庫單字（最接近的詞庫單字是polite）。問題在於oooorr 看起來不像polite，無法讓我們的大腦把兩字聯想在一起。我們可以接受自動校正功能把rhe改成the，或把firdt改成first，但無法接受oooorr變成polite。自動校正功能的目的，是根據你的行為，提供你想輸入的字，而不是運用某種精明的計算，無條件地把你的輸入改成詞庫的單字。我開發鍵盤程式碼時發現，有時讓用戶輸入的字母維持原狀，不用自動校正功能去取代，效果反而更好，因為有時輸入者確實想輸入那些字。超過某個臨界點時，出乎意料的自動校正可能使軟體令人困惑，不僅幫不上忙，還幫倒忙。這個臨界點在哪裡？我只能透過詢問夥伴來找答案，接著根據他們的意見回饋，挑選一個捷思式分界點來決定，我應該讓型態偏移演算法進行多少干預，以及何時不該讓型態偏移演算法干預。以這個例子來說，經驗吿訴我，我應該保留使用者輸入的oooorr，不讓自動校正功能去更動它。
其他時候，我們把演算法和捷思綁在一起。捷思產生的輸出結果，常變成演算法的輸入値。而演算法的輸出結果，又變成下一個捷思的輸入値。例如，在相片app中，滑向左側的手勢可以看下一張照片。這一切是從主觀判斷手指移動開始，也就是說，系統必須判斷滑動手勢應該顯示下一張照片，還是留在目前這張相片上（這是捷思）。這個判斷會輸入動畫程式碼中，它會根據你滑動的速度（這是演算法），以某個速度移走當前的照片，秀出下一張照片（這是演算法），並使用精心設計的動畫計時，讓照片緩緩地停在螢幕上（這是捷思）。
在科技與人文藝術的交會點運作就是這麼一回事。以上例子應該可以釐淸為什麼我們做那麼多演示。尤其，那個滑動相片的例子應該可以解釋，為什麼你無法在一個階段裡先運用程式設計一個產品，然後在另一個階段才賦予產品「外觀和感覺」。判斷哪裡該用演算法，哪裡該改用捷思，通常很困難。我們需要反覆進行多次的設計及程式編寫，才能評估所有相關的選擇。最好的做法是累積許多小決定，在我們試圖搞定如此繁雜又重疊的因素時，讓它們相互權衡。這就好像在拼一副拼圖，但我們不確定最後那一片長什麼樣子，而且那些拼圖的形狀一直在變。做什麼A/B測試都沒有用。隨著軟體一版又一版地改變，我們很難看出任何演示的選擇所造成的全面影響。我們覺得我們必須朝夕體驗軟體一段時間才能確定，體驗軟體如何融入生活，以判斷我們開發的東西是否符合最初的願景。我們的目標是精心組合一系列的演算法與捷思，以開發出讓消費者滿意又流暢運作的卓越產品。畢竟，設計是看產品如何運作。
這是一條很漫長的路。誠如賈伯斯介紹iPhone 時所說的，他從兩年半前就開始期待那一天了。
● ● ●
在iPhone 這種產品上，可以看到很多交會點，但有些交會點不盡相同。
賈伯斯在Macworld 大會上第一次正式發布iPhone 時，那是我的鍵盤與世界交會的時刻。賈伯斯在iPhone簡報中第一次向蘋果外界演示鍵盤的那一刻，害怕與恐懼取代了我原本心中洋溢的自豪感與希望。接著，他向觀眾介紹時，說我的鍵盤「不同凡響」，而且他順利地輸入一則簡訊。呼！我當場大鬆一口氣。坦白講，賈伯斯無意間在簡訊的結尾多空了一行，但那沒什麼大礙。他的演示沒出大差錯，這讓我如釋重負。演示很順利，那很酷。
此外，還有我和賈伯斯的交會。iPhone發表會結束後，我和理查穿過大廳，走上舞台，跟Purple軟體開發團隊的其他成員會合。我們接近舞台時，從賈伯斯的身邊走過。賈伯斯轉過來看我們，他馬上認出理查並向他道謝。這是我第一次見到他本人。他雖然知道我的工作，但他不知道我是誰。在蘋果有史以來最盛大的發表會結束後，我走向這個大人物，但他竟然沒看到我，這實在令人失望。
另外，iPhone 也和懷疑者交會了。Macworld大會結束不久，就有人對iPhone提出質疑。這些質疑的說法中，也許後來最出名的是微軟執行長史蒂夫．鮑默（Steve Ballmer）的嘲諷。他得知iPhone後的第一反應是：「五百美元？全額補貼？綁約？我覺得那是全世界最貴的手機，對商務人士毫無吸引力，因為它沒有鍵盤，很難當作一個收發電郵的好裝置。」
時間已經證明鮑默的說法錯得離譜。即便如此，在iPhone亮相不久，從另一個史蒂夫口中聽到不同的意見也不錯，這很有趣。接著，我們來到這章的主題：iPhone和我們為了開發它所下的工夫也有交會。這又把我帶回我在本書中提過的一個基本問題：為什麼像iPhone這樣的產品，會獲得那麼好的迴響？現在我已經準備好提出我的完整回答了，這主要可分三部分來談。
第一部分是善用演示的創意競擇流程。把這個創意流程加到「在交會點運作」的概念上，我可以進一步說明我們開發產品時，如何製造許多變化。
我們有一個想法時，會立刻用演算法與捷思拼湊出初步的版本。接著，我們匯集其他的輔助資源（例如程式碼、圖形、動畫、聲音、圖示等等）來製作演示。做完演示並與彼此分享一些意見回饋後，我們做出可以改進產品的決定─很多時候，這往往是指調整一些捷思，或修改演算法與捷思結合的方式。無論是什麼，我們所做的具體修改促成了下一次演示。這個流程一再重複。這種反覆進行的流程，使我們的專案走上一條不斷累積正面改變的漫長道路。這是我們從想法出發，最後為產品開發出軟體的歷程。
第二部分可以回到本書的前言，當時我第一次提到蘋果開發產品的七個要素。我希望大家讀到這裡已經明白那七個要素有多重要，以及它們如何為創意競擇提供素材。我把那七大要素再列一遍，這一次，我以本書提過的實例來補充說明每個要素：
1. 靈感：這是指放膽思考，想像各種可能。例如，伊姆蘭想到，流暢的指尖軌跡是消費者透過觸碰跟iPhone互動的關鍵。
2. 合作：這是指與他人同心協力，想辦法結合互補的優點。例如，達林和特雷幫我解決了WebKit文字處理軟體中的插入
點問題。
3. 技藝：這是指運用技能創造優質成果，不斷地精益求精。例如，Safari團隊利用網頁載入測試（PLT），使瀏覽器的運作速度愈來愈快。我們靠這個測試吿訴我們軟體的狀況，並運用那些資訊來精進程式碼。
4. 勤奮：這是指下必要的苦功，絕不巧取捷徑或敷衍了事。例如，我們埋首完成修復交叉引用的枯燥工作，成功地建置Safari，終於看到黑色方碑出現。
5. 果斷：這是指做棘手的選擇，拒絕延遲或拖延。例如，賈伯斯要我當場為iPad 選一種鍵盤設計，而不是在iPad 中提供我和巴斯開發的兩種不同設計。
6. 品味：這是指培養靈巧的判斷力，找到那個令人愉悅又完善的平衡點。例如，我們最終決定在iPhone上提供QWERTY鍵盤。
7. 同理心：這是指試著從別人的角度看世界，開發出適合他人生活及符合他人需求的東西。例如，赫茲寫了一個遊戲程式，以找出最適合點擊的圖示尺寸，讓大家可以輕易點擊iPhone螢幕，同時滿足手指靈巧度不同的人。
我還有很多其他的實例，例如，理查首次做瀏覽器演示以展示Konqueror瀏覽器程式碼的潛力，帶給我們靈感。而且，他在兩天內就搞定這個演示，由此可見其專家級的技藝。當葛瑞說出那句：「喔……拜託！你就不能一個按鍵只放一個字母嗎？」讓我把QWERTY鍵盤改成一鍵一字時，那是我職涯中遇到最果斷的情境之一。為iPhone建立自動校正詞庫，增添詞彙並調整所有字彙的使用頻率，以打造出涵蓋數百萬單字的詞庫，需要持續的勤奮努力。無數捷思的調整決策是由巴斯和伊姆蘭這樣的設計師做出來的，他們有無可挑剔的品味。在第一版iPhone 上的每個手勢與互動中，都可以看到這類決策。同理心讓我們把滑動解鎖功能設計得很直覺，連幼童也會用。我搞砸了管理一個軟體團隊的機會，但史考特依然讓我加入Purple專案─他豁出去相信我有合作的能力─因為他相信我有實力可以貢獻，只是需要一個合適的角色。
關於這些實例，我想提一件重要的事，因為你可能也會想到。我舉的一些例子看起來微不足道，似乎無足輕重。例如，赫茲製作點擊圖示的遊戲時，他抱持多少同理心？葛瑞宣稱我應該改回傳統QWERTY鍵盤的一鍵一字設計時，他有多果斷？
但這些質疑都沒有抓到重點：我們時時刻刻都努力培養品味、協作、勤奮、精進技藝，做所有的事情都是如此。每件事情都很重要，沒有什麼細節是無關痛癢的。
這也帶出了我的答案的第三部分。除了創意競擇及七個必備要素以外，我們還需要一個交會點才能開發出卓越的產品：人才與致力投入的結合。創意競擇與七個必備要素是最重要的產品開發要件，但蘋果還是需要一群致力投入的人，為這些概念挹注活力，把它們轉化為企業文化。我們營造的文化與我們創造的產品是密不可分的。根據我的經驗，這種企業文化的養成在團隊規模小的時候，效果最好，因為這時人際互動很自然豐富，而不是偶爾互動一下又很快結束。我在本書中描寫的專案團隊，規模確實很小。在宣布測試版之前，Safari團隊只有十人負責寫程式碼。iPhone的949專利上，發明者僅列了二十五人。雖然這兩個數字是衡量不同的東西，但大致上意義是相同的。這兩個軟體團隊都不是由幾百或幾千人組成。蘋果從賈伯斯開始，由上到下是採用務實的管理理念。我們的領導者想得到優質的結果，他們想和實際做事的人直接互動、做演示。這樣的想法對團隊的規模產生了限制，也產生了漣漪效應，因為開發團隊的規模小可以賦予個人權力，也培養團隊的凝聚力。這些因素很重要，許多龐大團隊的管理者企圖提升團隊動力時，他們往往把這些因素列為首要，卻礙於團隊規模而難以實踐。有效率的溝通是小團隊自然而然就具備的另一個特質。我們幾個團隊成員之間的溝通管道暢行無阻，互動就像輕車熟路一樣稀鬆平常，這讓我們通往目的地的旅途變得更加輕鬆。在前往目的地的過程中，我們總是盡量前進，盡可能避免猶豫與拖延。
最後一點正好是我在蘋果從事產品開發時，記取的第一個重要敎訓：取得成果的速度，可能比我所預期的還快。理查最初的瀏覽器演示讓我明白，如何啟動專案，如何運用靈感、技藝、果斷與品味，如何啟動連串的創意競擇。我和唐看到理查演示Konqueror的那一刻起，我們就很樂於融入蘋果這種作風明快的產品開發文化。我們並非特例，跟我同時加入蘋果的人也有機會參與一些出色的專案。當我們意識到機會時，我們齊心協力地投入，努力不懈。
所以，底下是我對蘋果模式的看法，是我們為Safari、Web-Kit、iPhone、iPad 等產品開發軟體的祕訣，也是我們能夠開發出卓越產品的原因：
一小群人以七個必備元素為基礎，透過持續不斷的創意競擇，塑造出一種工作文化。
進一步闡述如下：
一小群充滿熱情、才智、想像力、創意、好奇心的人，以靈感、合作、勤奮、技藝、果斷、品味、同理心為基礎，塑造出一種工作文化。他們透過反覆的演示與意見回饋，不斷地調整及精進捷思與演算法，堅持不懈地克服疑慮與挫折，在每一步中挑選最有前景的進展，以期開發出最卓越的
產品。
在談交會點的這章中，把這段闡述放在這裡，可說是再恰當不過了。誠如好萊塢所說的，這非常「依賴執行力」，也就是說，成果的品質主要是看執行的品質 。這一點也不奇怪，畢竟成果的好壞往往是看參與的人、使用的工具，以及那些人決定怎麼運用工具而定。
上面的進一步闡述也可以做為產品開發的願景，我們把它視為一個實際的問題。我們找好工具後，就開始投入，希望我們開發的設計及編寫的程式碼可以幫我們實現製造卓越產品的夢想。
本文摘錄自《創意競擇》，臉譜出版。
