這篇文章希望向你分享的是：如果你想開發一款App，而你請不起一個完整的開發團隊，那么你如何借助外包公司來做好這件事；你如何去攬下立項、原型、系統、UI、交互，這些所有的工作，幾乎沒有任何面對面的交流，一切想法都通過文檔來跟外包溝通，最終拿到一個跟你的預期絲毫不差的精品App。

由于字數過多，這篇文章分為了上、下兩篇來發表。你現在看到的是下篇。（上篇《探索外包開發的極限：一個精品App誕生的全過程（上）》）

五、UI設計/切圖/適配文檔：左右腦同時開工來制作擬物UI

由于是擬物設計且注重顏值，「the App」的UI制作將會耗費成噸的開發精力，既包括我要一個人承擔所有的UI設計工作，也包括要耗費大量iOS外包開發的Manday——我沒有機會出錯。

我沒有條件去盯著開發者的電腦，告訴他：“這里再往上1pt”、“這個按鈕再往右一點”、“iPhone 6 Plus的啟動icon再調大一點”——我必須在開發之前徹底講清楚所有的問題，把每張切圖、每個排版細節、每個機型的適配方法都考慮進去——只通過一套文檔，中間幾乎沒有任何溝通，開發者只出一個版本，就讓「the App」的UI在所有iOS機型上完美呈現。

正式做UI之前，首先要做每張頁面的概念圖，原則很簡單——盡可能地偷懶，有些不重要的頁面你甚至可以直接拿別人的截圖來代替。我見過很多UI設計師在設計概念圖時很糾結，來來回回對齊不同的圖層，統一各種字號或顏色，這樣的勞動除了讓你多加班之外毫無意義。做概念圖最緊要的就是“灑脫”二字。

不要有太多顧慮。當我做頁面B的時候，我無需去考慮它的美術風格是否要跟剛剛做的頁面A統一起來，因為說不定我在頁面B上突然有了很好的設計靈感，做出了比頁面A更漂亮的界面，那么反過來我重做頁面A就是了。把每個頁面當做一個獨立的平面稿來設計，這將大大節省你找到最優設計方案的時間。

（1/2）文件夾頁面的概念圖（左）

在幾天的概念設計之后，我發現其中2個頁面比較有意思。第一個是文件夾頁面，這個頁面是用戶在首頁（上圖右）點擊某個文件夾之后跳轉進來的。我發現，如果讓文件夾頁面變成墻壁的延伸（上圖左）會很有意思——用戶在首頁點擊某個文件夾之后，其余的文件夾直接消失，整個墻壁（包括光照）直接往右邊平移，挪出左邊的空間，然后文件夾下面的紙張統統飛到右邊，形成文件列表。在我跟智超討論之后，這套酷炫的轉場效果被暫時擱置，因為我承擔不起它所耗費的Manday，不過這并不影響我把文件夾頁面確定成這樣的設計，因為它最符合故事的情境。

（2/2）寫作頁面的概念圖

第二個讓我感興趣的是用戶寫東西的頁面（上圖），我當時找來了很多主流日記、記事App的寫作界面截圖，發現其中那些比較優秀的UI都有幾個共性：

1. 文字一定要大，行間距和段間距也要大，這樣你就算只寫幾十個字也很有成就感，仿佛是寫了一篇大作。
2. 光標不能用默認的，要用大的，閃爍起來要有呼吸感，而且最好不要被行高限制住，要往下延伸到下一行的頂部，這樣能激發人的寫作欲望。
3. 最常用的按鈕不要放在頂部，而是放在鍵盤上面，而其中最重要的那個按鈕要放在右邊，這樣寫完了之后不用抬手，右手大拇指輕松就能點到保存（老羅調研過，手機用戶中，右手為主的用戶比例雖然低于生活中右手為主的人，但還是輕松超過一半）。

所以，我就截了幾張UI放進設計稿里，簡單拼湊了一下，照葫蘆畫瓢做了個左圖中的UI，順便把鍵盤改成跟上半部分統一的黑白色（iOS原生輸入法可以定制顏色）。

我覺得這樣的寫作頁面沒有什么需要畫蛇添足的地方了，再減一個元素就影響使用，再加一個元素就導致臃腫，那么現在我手上有兩個頁面的UI概念圖都達到了我要的標準。

但問題是，它們一個是純擬物，一個是純扁平，這要如何是好？經過思考，雖然「the App」強調的是擬物，但是我可以把“擬物層”和“操作層”做成兩種對撞的風格——所有關于紙張、墻壁這些“物理環境”的設計都做成純擬物，而所有交互的內容都做成純扁平的，這樣看起來效果最好。如果我一根筋地去把所有的交互界面都做成擬物的，反而會弱化紙張和墻壁的擬物感。所以我決定把“操作層”做成扁平的，讓薄如蟬翼的“操作層”漂浮在厚重的“擬物層”之上，就會在帶來沉浸感的同時，給人一種操作起來很輕便的感覺。

依照這種設計思路，扁平和擬物的風格不需要強行統一，反而是對比越強烈效果越好，這就讓我面臨一個問題：怎樣的扁平設計是最純粹的？

你認為哪個扁平設計更純粹？

左圖是一個很純粹的扁平UI設計；右圖相反，是一個四不像的扁平UI設計。左圖之所以夠純粹，仔細觀察可以發現原因：

1. 雖然顏色看起來很繽紛，但除了不同透明度的白色之外，實際上只有黃、藍對撞色。
2. 所有的圖形，甚至包括字體，都是圓角的，圓角的半徑也基本是相同的。
3. 字體看起來很多，但實際上字體和字號都只有一種，看起來多只是因為顏色或加粗帶來的效果。

當時研究了很多例子，發現優秀的扁平化設計，毫無例外可以用一個觀點來概括：能用一種字號解決的，不要用兩種字號；能用一種顏色解決的，不要用兩種顏色……所以我就帶著這種思路重新整理了一下其余的概念圖（這就是為什么不要那么早確定設計標準），基本形成了「the App」在“扁平化”部分的設計規范：

將所有系統字精簡為“大”、“小”字

1、兩種字體

（１）系統默認字體

除了用戶自己寫的文字內容需要單獨來制定字號、行距、段間距之外（因為這個內容最重要，需要區別設計），其它情況盡量用2種規格來解決（見上圖），那就是“大字”和“小字”。在設計規范中，我分別定義了兩種字體的字號、行距、段間距。

得到它們具體規格的手段很簡單，就是去復刻那些優秀App界面中的字體，把它們應用到你設計稿中的若干個主要頁面中，輸出成幾個重要機型的效果圖，分別放到這些機子中去看實際效果，反復微調幾次就基本搞定了。在這個過程中，不要像很多人那樣，總是填上那些排版最好看的文字內容，而是要盡可能讓文字的排版丑陋。例如，一行字多出一個字跑到第二行，連續兩次空行，連續敲很多個句號……你永遠無法預測到用戶會輸入什么文字，如果你能在文字最不適合排版的情況下，也能保證排版看得過去，那么你設置的字體才是最有適應力的。

用“刻宋”體作為交互類字體，提升UI檔次

（２）自帶字體

這是由于我發現，之所以很多中文App用同樣的設計方法來做扁平化UI卻比不過歐美，很大程度上是因為字體的丑陋。

扁平化設計中，字體是很主要的視覺元素——英文App可以隨隨便便就嵌入一個幾十k的字體，而中文App嵌入一個字體就意味著多幾M的大小，而且簡體字體制作成本超大（5000多個常用字），做出來也很少人有付費意識去買正版，所以精益求精的字體也很少。于是我購買了為數不多非常耐看的造字工房的“刻宋”體，除了一些非常重要的標題之外（例如用戶自己起的標題），我將盡量讓它只擁有一個最適合手指點擊的字號，用來擔任絕大多數點擊類的字體。

黑白是更純粹的扁平化設計

2、黑白設計

既然扁平化越純粹，就能越凸顯擬物和扁平的反差之美，那么我能想到的最極致的方案就是全黑白設計。市面上大多數App的UI設計濫用各種顏色，到處都是不同的彩色：這里需要強調，于是用綠色，那里更需要強調，于是用紅色，還有個地方是重大通知，于是就用紅色加粗加大，弄到最后，就變成了電線桿上的老軍醫廣告。最極致的扁平化設計，就是拿最少的元素，把它們組合成最合理的視覺搭配，讓它們自然地形成主次之分和操作引導。如果非要用紅色才能突出某個視覺重點，只能證明我的版式設計還不夠智慧。

《版式設計原理》，佐佐木剛士

關于版式設計，我當時買了佐佐木剛士的《版式設計原理》，版式設計是日本的傳統強項，而且日語跟中文在視覺上有很多類似之處，它們都不能完全照搬英語系的版式設計美學。紙質讀物的設計元素很有限，大部分內容都是黑色的字，沒有現在手機UI那么多變的視覺表現力，那么在設計元素匱乏的情況下，怎樣區別不同內容的輕重程度，讓讀者能自然地按照你設想的順序去閱讀這些內容，這就是版式設計的智慧。從以前的紙質雜志到現在的扁平化UI，變化的是媒介，不變的是人類的視覺習慣。

化繁為簡的“設計規范”

把每個頁面的效果圖基本跑通，然后盡我所能地抽象其中的設計元素，我就得到了上圖這些設計規范，具體包括：導航欄的布局、常用對齊線、常用圖文按鈕排布方式、常用列表類頁面布局等等……這就是我為什么強調一開始做概念圖的時候不要先確定設計規范，而是放開靈感去做，因為它們實在太難以預測了。只有把所有頁面效果圖確定到七七八八，你才能看到你需要多少種字體、多少種透明度、多少種對齊線……設計規范是用優質的概念圖總結出來的，而不是一開頭就拍腦袋決定的。

基本確定了設計規范之后（并不是說要100%確定下來，因為在具體設計的過程中，設計規范的添加或修改是在所難免的），接下來就是做正式效果圖，這個環節跟扁平化UI設計會有一些不同：

1、100%還原圖

扁平化設計中，你可以只做大致的效果圖，做效果圖的目的只是確定UI文檔該怎么寫，前端看的是文檔，效果圖只是視覺參照。在一個優秀的扁平化UI制作流程中，幾乎所有設計素材都是單獨儲存的，有一個完整的素材庫，只需按照設計規范把這些素材一個個擺進設計稿里就行了，而在設計稿里新產生的素材也會被迅速加入素材庫中。最后它們可以從素材庫里一次性切圖。

擬物元素不能相互遮擋

但在「the App」中，很多視覺元素是擬物的，如果我不在正式界面里做到100%還原，我就沒法確定一個文件夾的封面是不是會不小心壓住上面的吊燈（上圖左）；也沒法確定文字的標題是否會跟“孔”重疊起來（上圖右）。因此，我必須把涉及到擬物的頁面效果圖做到100%還原，以此來撰寫我的適配文檔。

2、最大機型畫布

扁平化設計中，一般效果圖只需要做一個大小適中、主流的機型，例如很多人在設計iOS App時只做iPhone 6的效果圖。然而，位圖跟矢量圖不同，它只能縮小不能放大，所以我的100%還原圖必須用6 Plus畫布來做，因為很多擬物切圖要直接從這里取材。

同時我還要另外去做各種小機型的，不必100%還原的效果圖，來確保我的對齊方案在任何機型上都不會反常（例如，上文提到的，不能讓封面遮住吊燈）。

鑒于以上兩個原因，我就開始去做主要頁面的iPhone 6 Plus 100%效果圖。這里的“主要頁面”包括兩類，一類是需要從效果圖中直接拿到切圖資源的頁面，也就是擬物設計非常強的一些頁面；另一類是模板類頁面，例如我們有三四個列表類頁面，顯然只做好其中一個就行了，其余的無需煞費苦心，只要一個大概的效果就足夠了。

做完上述工作，就要開始出正式文件了。對于前端開發而言，需要的正式文件包括：效果圖、適配文檔、切圖。這個章節的標題提到左右腦同時開工，之前的工作用右腦就能完成，而從這里開始就得用左腦了。

為了解決全部的適配問題，我先解決一個小問題，我的工作從這5張“紙”開始：

統一處理App中所有出現過的“紙”

這5張紙是「the App」UI中所有會出現的紙，為了適配方便，我得把它們的文本位做成相同的。由于最右邊兩種紙的左上角有回形針，所以“標題”統一往下調整，以免壓住回形針。

用RGB通道來確定“紙”的切圖范圍

紙的光環境是燈泡從右上角照過來，因此它陰影的邊緣自然在左邊和下邊。為了拿到切圖，我必須確定邊緣，從效果圖（左上）里直接找到邊緣很困難，用通道+曲線很容易就找到了（左下）。有了左下角的邊緣之后，我就能完整把它切出來。為了文本對齊方便，顯然我在紙張的頂部和右邊也要留相同的空隙，這樣紙張切圖“紙”的部分就能剛好處在切圖的中心（右）。

形成“紙”的統一文檔

那么接下來就是給這張通用的“紙”來寫文檔。見上圖：

1. 文本框的寬、高，以及它相對于這張紙切圖的位置，我都用它們與切圖尺寸的比例關系來表示。這樣做之所以可以成功適配，是因為不論紙張有幾種規格的切圖（@3x、@2x，或以后更高規格的切圖），我們要明白一個特點，那就是文本框與切圖的比例關系是不應該發生改變的。
2. 標題的底部距離文本框的高度，并不需要用具體數值來表示，而是可以剛好隔開一行文本的距離，那么在文檔中我就定義這個距離=正文的字號。也就是說，假設正文的字號是12pt，那么它們的間隔就是12pt。這樣做的好處在于，不論我怎么調整正文字體的大小，標題與正文看上去永遠剛好隔著一行。
3. 標題的字號不是一個具體的數值，而是正文字號的1.4倍。因為從設計上來講，標題之所以看上去是標題，就是因為它比正文的字要更大或者更粗。1.4倍剛好可以體現這個關系。當我后期要調整正文字號的時候，標題就可以隨之而改變大小，無需我手動去調整了。
4. 紙張下方的小字，由于切圖底部已經留出了空隙，所以直接讓它0間距對齊就行了。

從上面整個文檔來看，幾乎所有的“約束條件”（元素之間的相對空間關系）都是用“比例”來表示，這就意味著，前端工程師只要把這套條件放進去，我們就無需考慮具體的機型，大到iPad小到iPhone 4都能完美呈現。同時意味著，如果我們對其中某個地方不滿意，也無需去修改每個機型的數值，而是從宏觀上去修改某個比例關系就行了。

而唯一能影響這些比例關系的變量就是正文的“字號”（切圖大小是固定的，所以它不會影響比例關系），所以接下來就是來定義這個“字號”了。

（1/2）“日記字”在“紙”上的不同大小

首先，見上圖，這張紙在iPhone 6P的3倍圖里，和在iPhone 6/5/4的2倍圖里，有兩種不同的大小。（2倍圖是共用的，我必須在最窄的屏幕（iPhone 5s、5和4）中確定2倍圖的大小，以免紙張太大，遮住了右邊的吊燈和封面）3倍圖比較大，2倍圖比較小，如果字號相同，那么2倍圖容納的字數就會少很多。然而，從產品理念上來講，我希望不同機型上的紙所容納的文字摘要字數基本相同，因為字數太多會導致很多紙張顯示不滿，給人一種空虛的感覺；而字數太少就沒法形成摘要，每張紙都要點進去才能知道具體寫的是什么。

為了滿足這個理念，具體某個分辨率紙張上的字號，就應該跟紙張的大小掛鉤。紙越大，字號就越大，紙越小，字號就越小——這樣就能保證每個機型所顯示的摘要字數相近。這個概念確定之后，先別急，再來看閱讀界面的字體。

（2/2）“日記字”在閱讀界面的不同大小

感覺到了嗎？在閱讀界面，同樣是這個道理（如上圖）。如果我只設置一種字號，那么要么是6plus用戶覺得字太小，寫很多內容都撐不滿屏幕，沒有成就感；要么就是小機型用戶覺得字太大，一屏幕只能看幾句話——我同樣應該設計成：大屏幕字大，小屏幕字小，所以，結合上面的“紙”，你應該猜得到我打算怎么做了——

用一句話來概括所有的“日記字”

如圖，所有機型，不論是閱讀頁面的字，還是紙上的正文，它們用這簡簡單單一套規則就可以概括了。我們確定唯一的參照標準，就是當文本框寬度為363pt的時候，字的大小、行距、段間距分別是21pt、10pt、14pt，而其它所有的情況，無論是6plus紙上的字號，還是iPhone 4閱讀界面的字號，都從文本框的寬度直接換算比例得到。

以上就是「the App」UI制作的核心思想：把幾種機型幾十個頁面的不同元素，從設計的角度把它們歸納起來，用一層一層的變量關系來嵌套，像一棵樹那樣，追溯到最后，它只有為數不多的幾個數值。改變這幾個數值就能改變整個App。

這些為數不多的數值就是前端層面的“設計規范”，它與UI制作的“設計規范”實際上是一式兩用的。在前端上，它們形成了設計規范的“宏”，這個宏定義了UI適配中的所有變量。當我描述一個長度的時候，我并不說這個長度是15pt，而說它是1.3{小字}，這里的{小字}就是一個變量，往前追溯，就能查詢到我對“小字”事先約定的設計規范。

下面再舉幾個例子。

一套規則，適應所有機型

在上圖中，由于中間的選項文字的段落屬性是居中的，所以確定左右25%的對齊線就能讓他們容納最大字數的內容，而不會超出屏幕。唯一需要用數值來表示的是這些具體選項之間的間距，這里定義它是43pt，因為經過測試，小于這個距離就容易誤觸（這類情況比較少，否則可以定義一個叫做{最小按鈕間隙}的變量）。然后，這個主要模塊當然可以定義成居中于屏幕，于是我們就可以進一步定義：上、下模塊各自從剩余的空間中取得中心對齊線——整個界面只有1個具體數值，其余都是變量，且適配于所有機型。

同樣，一套規則，適應所有機型

在跟用戶寫的文字相關的界面中（例如上圖），用戶的文字是{日記字}的格式，它是這些界面視覺的核心，所以大部分的間距都要跟著{日記字}的段間距來走。確定了大致的視覺之后，把各種間距換算成它與{日記字}的比例關系。當屏幕變大變小，{日記字}會隨之變大變小，而不同的間距都會隨之變大變小，但它們看起來永遠是和諧的，因為思考這些變量關系本身就是在思考“各種視覺元素以何種比例關系呈現出來才是最有美感的”。

將所有切圖匯集到素材庫，統一管理

當切圖都匯集到素材庫（上圖）之后，還要給每類切圖都單獨制作一份適配文檔，這是由于擬物UI的復雜性導致的。扁平化UI中，一般我們會把一個具體的切圖定義為只有一個規格，例如不管在3倍圖還是2倍圖中，某個按鈕的大小都是30pt * 50pt，這樣它在不同的分辨率中都會有相近的物理大小。

BTW：

之所以手機開發用的單位不是px（像素）而是pt（點），就是因為每款手機的像素顆粒大小不同，屏幕的精度（ppi）越高，單個的像素就越小。

假設你定義一個字的字號是99px，這就意味著這個字的高度是99像素，你在你的電腦屏幕上看它有一個櫻桃那么大，在iPhone 4里看它有大拇指指甲蓋那么大，但是在iPhone 6 plus里看起來就只有黃豆那么大了。這是因為6plus的屏幕精度很高，在一個黃豆的尺寸里就有99 * 99個像素。

所以為了設計師的方便和機型的轉換，大家就設計了pt這個單位，你在iPhone 4的效果圖里設計了一個60* 60像素的圖標，放到iPhone 4里看起來是一個小拇指蓋的大小，你覺得剛剛好。那么由于iPhone 4的1pt = 2px，所以你就告訴程序員說，這個圖標的大小是30 * 30pt。

某一天你打開iPhone 6 plus，發現這個圖標看起來也是小拇指蓋的大小，這是因為6plus知道自己像素很小，所以它告訴你的App說“我的1pt = 3px哦”，所以你的App就自動把這個圖標放大到90 * 90像素給它了（當然前提是你切圖格式是矢量pdf，否則就模糊了）。

過了10年，iPhone 100問世了，它的像素密度已經高到了匪夷所思的程度，但是蘋果工程師聰明地設置了1pt = 1000px（當然了，這已經超過人眼極限，這里只是夸張舉例），所以你這個App在iPhone 100里打開，它依然是小拇指蓋的大小。

——跨越不同終端不同屏幕之間的差異，為人的眼睛去尋找一個統一的標尺，這就是pt這個單位存在的意義。

封面圖必須完美嵌入紙堆，不能有絲毫誤差

然而，「theApp」中的某些擬物元素并不能依據我們想要展現的物理大小來決定，而是要依據它與周圍元素的位置關系來決定。例如上圖中，封面的圖片必須完美地嵌入封面的切圖中，不能有1pt的誤差，否則看起來就不像是一個整體。這個時候，只能是下苦功，分別制作@3x、@2x兩個規格的切圖，然后老老實實量出圖片位的具體大小。

用切圖的留白，來代替復雜的適配

也有一些適配情況是極難用變量來描述的。例如，在上圖左的界面里，封面的兩張切圖要完美契合在一起，非常難適配，所以我就干脆把這個工作攬過來，直接在效果圖里設計好切圖，給這些切圖上下左右預留好精準的空隙。這樣，程序員就無需適配，直接讓兩個切圖中心對齊，就能呈現出最完美的視覺效果。

動畫效果“沖擊波”的時間軸設計

交互效果的設計則簡單很多，我們同樣先確定一些變量，然后用這些變量來描述具體的時間軸就行了。如果你使用過Flash或其它動畫、特效軟件，你一定很熟悉時間軸。實際上，你越熟悉時間軸，你就越不需要去做真正的動畫給程序員看，因為你能在腦子里很輕松地視覺化這些時間軸，很確定它能實現你要的效果。

不過要注意的是，變量的設計要巧妙，用最少的變量來給你的動畫埋下最多的后期可塑性。例如上圖是“沖擊波”效果的時間軸設計，我設計了變量o，調整o就能調整整個動畫的速度，而調整4o為其它倍數（例如5o、3o）就能調整“沖擊波”的寬度，兩者一起調整就能實現很多不同的視覺效果。

整個UI制作的過程是很苦的，但最終我實現了預期的設想——僅通過一次開發，「the App」的UI就基本在所有機型達到了完美的適配效果，后續的改動也很輕松，因為都是針對變量和比例關系的改動，無需在每個具體機型中反復調整。「the App」在這個階段省下的Manday足夠開發一個同級別的產品。

六、成本控制：虛擬迭代

「the App」曾經開發過1.0版本，雖然我對它的操作體驗下足了功夫，但是體驗只是給你產品加分的東西，它掩蓋不了一個產品的致命傷。如下圖，當時的設計是這樣的：

1.0版本的“微博”設計

假設一個想要寫下一條人生方向，例如：“我最致命的缺點是過分思考卻不行動”，這條人生方向就形成了一篇“微博”，而每當這個人有了關于對“過分思考卻不行動”的新看法，在生活中對它有了新的體驗，或是看到一篇文章講的也是這個話題，他都可以附帶上新的觀點來“轉發”這條微博。

當他每天打開某個文件夾，例如這篇文章所在的“行動的巨人”文件夾，他就看到了一個完整的微博小站。這些微博默認按照時間流來排序，他可以看到他最近轉發了什么，原創了什么。而當他切換到另一種排序方法的時候，「the App」只向他展示原創的微博，而且那些轉發次數最多的將會排在最前面，提醒他最重視的人生信念是什么。

上線前我對這套邏輯信心滿滿，然而上線后才使用了兩周，我就發現了其中的大問題。其一，越是轉發次數越多的微博，我就對原文越不滿意，因為我的思考一直在往前走；其二，當我靈感一現，想要掏出「the App」來寫東西的時候，我往往會愣住，因為我不記得我有沒有寫過類似的“原創”，如果有，我也很難第一時間找到它來轉發。于是，我往往都是寫去寫一篇新的原創，這套轉發機制逐漸成了擺設；其三，轉發次數最多的微博，并不一定是我最應該去堅持的人生信念，有時候，它反而代表一個我走過很多彎路的錯誤信念。

從這件事情之后，我決定「the App」以后每個版本在開發之前，都要經歷足夠多的“虛擬迭代”。這個名詞是智超后來幫我總結出來的，它的含義是：在產品真正投入開發之前，盡最大努力在內心去虛擬這個產品上線之后真正的樣子，不斷地“使用”這個產品，從這個“使用”過程中提前發現產品的問題，不經過開發，直接進行下個版本的迭代。

如果一個產品原先要開發10個版本才能成功，通過虛擬迭代，你可能用3個版本就能達到同樣的效果。由于「the App」是外包開發，所以我這邊“虛擬迭代”的時候，外包公司的人力費用并不需要我承擔，所以你可能會說，我的情況并不能適用在一個需要每天養活開發團隊的公司里。

但是反過來講，為了讓設計組、程序組不空轉，就強行趕鴨子讓產品組草率地設計一個版本出來，其中很多問題都沒有仔細驗證，上線之后立刻就改需求，一個想法接著一個想法，源代碼被弄得千瘡百孔，產品實際要解決的問題卻還沒找到關鍵的門路，隨時面臨打倒重來的危險，這樣難道就是有效率的企業運作方式？

PM一個人再厲害也有很多情況是考慮不周的。當產品設計在不斷“虛擬迭代”時，設計和開發組不必那么快就進入正式開發的工作，設計組可以趁這個時間多做一些概念圖，跟PM一起把產品視覺確定下來，一起跟前端工程師去探討每個細節的可行性。而開發組則可以提前梳理產品需要的模塊和技術，提前攻破某些技術難點，跟PM一起討論每個產品模塊的性價比：哪些該做，哪些該尋找替代方案……所有人坐在一起討論產品未來可能的走向，以便提前設計好一個拓展性最強的框架，減少未來迭代的成本——最好的產品一定是這個團隊所有人作為一個整體來完成的，強行劃分成策劃、UI、開發的步驟，或是強行說：“你是UI設計師，你不要參與功能設計”、“我不管你們怎么設計，我等你的文檔出來然后寫代碼”，這跟工廠流水線生產罐頭又有什么區別呢？

把產品設計在腦海里具象化

在「the App」開發中，虛擬迭代分兩步，第一步是讓我在腦海里具象化這個App上線之后的樣子，所以我會把效果圖都貼在白板上，盯著他們看，想象自己在這些頁面跳轉；我也會拜托智豪同學幫我把效果圖擺進墨客或Axure里，做成一個可以在手機里點擊的高仿真H5原型。

當我從這一步中建立了我對這個App整體的視覺和操作記憶之后，我就會進行下一步，那就是做一份Word文檔格式的“「the App」”，它很像桌游，我當做自己在使用真正的「the App」那樣操作它，每天記錄很多東西，就像是在使用真的App一樣。

我在辦公室、咖啡廳、湖邊和菜市場寫東西，我在醒著和睡著的時候寫東西，幾個月里寫了十幾萬字的個人思考和摘錄。每當我在原型或效果圖里覺得某個功能已經設計得很棒的時候，過不了幾天我就會在“使用”Word版「the App」時發現這樣那樣的問題，然后我就去修改設計方案，哪怕是打倒重來。

首先是第一次虛擬迭代。既然靈感來襲的時候，我也不知道到底該“原創”還是“轉發”，那么就去掉它們之間的差別——所有寫下的東西都是一篇“感悟”，我每次記錄的文字之間不再有高低之分。等到我閑暇的時候，我就把某些描述同一個人生道理的“感悟”匯集到一起。例如，我發現我有3篇感悟都是在反思自己容易情緒化的毛病，還有5篇是從網上收集來的關于情緒管理的文章片段，那么我就把這8篇內容匯集到一個“信念”之中，然后給它起名叫“控制情緒”。

第一次虛擬迭代：“打孔”

并且，一個信念的權重也不再取決于他所包括的文件數量，而是你給它打了多少次孔。每天用戶都將獲得一個打孔器，選擇當天對他生活起到真正幫助的那條信念，去給它打孔。日積月累，人生信念就會形成一個排行榜（如上圖）。

當你看到一篇信念有50次打孔的時候，你就知道，它在生活中給了你50次的實際幫助，也許它是一個不起眼的大道理，但是你應該堅持下去；當你發現某個以前看到流淚的心靈雞湯只有2次打孔，你就知道，原來它屬于劣質的地攤成功學，它講的都是虛的，它對你沒什么幫助。

然而，當我在Word版「the App」“使用”這套新設計時，我又很快發現了兩個大問題。

其一是我可以作弊。我并不是每天都對生活有新感覺，但這些日子里，如果我不用打孔器它就會被浪費掉，為了不虧，我就隨便找了個沒用的信念給它打孔。等到我有一天突然發現一個好的觀點時，我立馬把那個沒用信念跟它合并了起來，再把沒用的部分刪掉，這樣它的打孔數就立刻上升了。

其二是我的內容很亂。我最感興趣的一條信念是稻盛和夫的“做正確的事”，我每天都有新感想寫進去，但實際上很多并不是思想上有什么新的認識，而是我當天做了什么事。這些相當于流水賬的內容摻雜到信念里，讓我每天打開它不知道該看什么重點。

于是，在第二次“虛擬迭代”中，我設計了“涅盤”和“流水賬”來解決上個版本的問題。

第二次虛擬迭代：“涅槃”

如上圖，每個信念只能容納9個最精華的感悟，多余的必須要“涅槃”，涅槃實際上就是讓你從感情上接受去刪除那些不重要的思想，它約等于刪除，但它的“英靈”永遠存在于這個信念的一個小入口內，不允許徹底清除，供你瞻仰。

同時，用戶在打孔數上作弊也沒那么自在了，假設你為了把一個20次打孔的信念提高到50次，而合并進來一個打孔30次的不相關信念，那么當你去除那些不相關內容的時候，它將永遠保留在涅盤區扎你的眼，讓你不舒服。即使你先偷偷把那個不相關信念的內容都清除掉也沒門，因為信念的合并也包括它們涅盤區的合并。

而“流水賬”就能把每天的實踐體會跟那些具有指導作用的文字隔離開，有什么實踐體會，寫流水賬就行了，沒必要寫進信念里。但問題在于，寫流水賬這個功能并不在「the App」的主線上，而一個完善的流程設計應該是“你一定會按照我的設計來做”而不是“某個功能你可以用也可以不用”。這個時候，我犯了一個非常愚蠢的錯誤，那就是額外設計了一套“分數”機制來保證用戶會使用流水賬這個功能——有時候，你沉浸在你的勞動中，于是忘記了你也曾是鄙視某種做法的人。

第三次虛擬迭代：“流水賬”與“打孔”的結合

在接下來的“使用”中，我遇到的問題主要集中在流水賬的設計上。在第三個虛擬迭代版本中，我終于找到了解決辦法，那就是把“打孔”跟“流水賬”結合起來（上圖）。用戶如果要打孔，就必須結合這個信念寫下今天的流水賬，講一講今天為什么要給這個信念打孔，發生了什么，自己做得如何，有什么感想。例如，你今天遇到一個老油條給你甩鍋，但是你突然想起你寫的一篇叫做“不做老好人”的信念，于是你戰勝了這個老油條，那么今晚回到家，你就找到這個信念去給它打孔，打孔的時候你就寫上了今天的流水賬，講述今天這個值得慶祝的事情。

這樣的設計就讓流水賬融入了主線之中。另外，我設計了讓流水賬不能刪除，寫了就永遠在那里，以保證每次的打孔必須是嚴謹的而不能是隨意的。

在第四個虛擬迭代版本中，我還設計過一個叫“導航器”的東西，因為當我想要給一個信念打孔，或給它添加一個新的感悟時，有時候我很難立刻找到它。不過由于我一直堅信“附加功能”往往都是設計上智慧欠缺的遮羞布，所以我最終發現原來問題的癥結來自于現有排序規則還不夠完善，于是我就去掉了這個功能，然后完善了排序的規則。

最終，第N個虛擬迭代版本在我UI制作的一個月反復“使用”，一直沒有發現新的問題，于是我就提交文檔給外包公司正式開發了。中間收到過30個左右的測試Build，經歷了大概80次電話溝通，3次當面溝通和2000個左右的需求提交（包括Bug、細節改動，使用Worktitle平臺），接著就有了現在的「the App」2.0——感謝我的朋友李穎、陳智豪、劉明清，后面這些工作很多是由他們幫我完成的，我一己之力是根本無法做到的；也感謝我的外包公司的老板鄧智超，「the App」做到后期，很多模塊的Manday都遠遠超出了預估，但是他沒有多收我一分錢，因為他也逐漸愛上了這個產品。

虛擬迭代畢竟不是真實迭代，我總有一些地方會犯錯，我會收到用戶的各種反饋，正確看清這些反饋，我才能知道下一個版本迭代的重點在哪里。

《守望先鋒》，源氏

《守望先鋒》現在逐漸退熱，很多用戶都在抱怨各種問題，主要集中在英雄這個話題。有的抱怨“不能玩源氏了”，有的抱怨“DVA太強了應該削弱”，有的抱怨“憑什么我每天要玩奶媽”，有的抱怨“說好的一個月出一個英雄呢？”……

如果暴雪一條一條去改正這些問題，它就輸了，因為這些抱怨背后的原因都是一致的——那就是過分強調團隊配合。一個團戰基因太強的游戲（參見暴雪的《風暴英雄》），它必然導致很多人要補位，因為所謂的配合體系就是“肉、DPS、奶”的固定搭配；它必然導致每個版本都會出現一些最強勢的英雄組合，于是就有人玩不了源氏；它必然導致出英雄的難度會隨著英雄數量上升而呈幾何指數加大，因為策劃需要考慮的不是單個英雄之間的平衡，而是巨量的英雄組合之間的平衡，于是就有人抱怨出新英雄的速度太慢……

用戶會向你暗示產品的問題，但很少能直接指出產品的問題。你要做的不是挨個地去滿足每個用戶的需求，而是去思考它們背后指向了產品的哪個根本性的癥結。永遠都會有人抱怨和質疑你的產品，你要做的不是去迎合，而是借助他們的智慧來更徹底地做自己。

「the App」在Appstore的平均評分是4.5，它的評分是兩極分化的，好評的人給的幾乎都是滿分，有些人寫了幾百字的評論；差評的人有時給的只有1分，然后配上“垃圾玩意兒不知道怎么用”這種憤怒的文字。但在我眼里，不論是給最高分還是給最低分的人，他們使用「the App」的體驗都是一樣的，我不能因為那些好評就認為「the App」只不過是門檻比較高，對于有心鉆研的用戶才能敞開他的大門。實際上，給最高分的人，他們所認同的是「the App」優秀的那一面，從用戶交流來看，他們一樣會遇到那些給1分差評的用戶遇到的問題，只不過他們對「the App」更加寬容罷了。

有些人反映“進去不知道怎么用”，有些人反映“是不是雞湯App？”，有些人反映“教程太過文藝”，有些人反映“建立了一個文件夾之后，不知道怎么開始寫”，有些人反映“信念和感悟到底有什么區別”，有些人反映“打孔器到底是干嘛的？”。經過對產品核心的審視，這些問題的產生絕大多數都來自于同一個錯誤，那就是我之前提到的，那個愚蠢的錯誤——為了把流水賬功能融入主線，而額外設計了“分數”這個體系。雖然后來我改變了流水賬的設計，但我并沒有去掉“分數”這套體系。

由于“分數”體系綁定的是文件夾，而文件夾代表的是“人生目標”，所以目前整個「the App」的主線上，都會過于強調“人生目標”這個概念。由于“人生目標”卡在「the App」和用戶內容之間，我就無法避開它來直接呈現「the App」的核心思想，我還得另外去寫一些教程來引導用戶，完整的用戶流程中間出現了一個多余的環節，于是就產生了上述用戶所抱怨的一切。

每個the App用戶所追求的，都是成為更好的自己

實際上，大多數用戶，包括我本人，只是偶然看到了書上一句點亮人生的話，只是偶然走在湖邊，突然想通了從今以后要怎樣面對這個世界。然后，我們不約而同地打開了「the App」，只是想把這句話寫進去，再在閑暇時把他歸類到某個人生信念里，以便讓雙眼能更加清晰地看到前方的路。在這個過程中，我們并不關心人生目標是什么，因為所有「the?App」用戶的人生目標都是一致的，那就是去做更好的自己。

但如果不是虛擬迭代，我也許要在第5版、第10版才能發現這個問題，而不是在第3版就能解決它。在「the App」接下來的2.1（或3.0）版本中，你將會看到一個更簡潔但更有智慧的個人成長應用。

整個「the?App」的開發過程，如果說有什么最重要的信念，那就是在極力減少每個版本Manday的同時，用虛擬迭代的方式讓每個版本之間的跨度盡可能地擴大，因為一個產品很少在第一版就能成功，在有限的成本內，我們需要更多的、更有質量的試錯空間。

在給「the App」做UI之前，我的設計水平還停留在剛畢業時業余設計一些公益廣告的階段，我并不知道@3x的真正意義是什么，那么我就去查知乎、研究別人的作品，用盡各種辦法把首頁做出來，啃下這塊硬骨頭之后，后面的UI設計也就輕松多了；

ASO和H5架設我都沒接觸過，那么我就去萬能的淘寶，看那些店家說自己是怎樣做的，然后動手學過來；

當我在人員完備的互聯網公司里做產品時，我曾對外包開發嗤之以鼻，覺得不天天盯著開發豈能做出一個滿意的產品來？而后來，我們認識了智超，然后我們做到了。

過程很簡單，那就是像「the App」所要求的那樣，去不斷追求更好的自己。

【全篇完】

相關閱讀

探索外包開發的極限：一個精品App誕生的全過程（上）

作者：黃聯樵（微信：arubagod），歡迎交流。

本文由 @黃聯樵 原創發布于人人都是產品經理。未經許可，禁止轉載。