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

全文目錄：

【上篇】

一、解決一個問題就夠了（產品定位/需求分析）

二、拒絕數學公式，用感性來立項（產品立項）

三、直接開始設計App的門面（概念圖/交互設計）

四、用避免“反人類”的方法來設計原型（原型設計/文檔撰寫）

 

【下篇】

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

六、虛擬迭代（成本控制）

由于字數過多，這篇文章會分為上、下兩篇來發表。你現在看到的是上篇。

前言

我耗盡心思寫這篇文章，并不是想要給我的App打廣告，而是總結我過去一年創業開發這個App的過程中探索到的所有關鍵性的經驗，將它們凝聚到這27000字里，供給所有對App開發有興趣的人了解——因此，本文所有涉及到App名稱的地方，都會用「the App」來代替。

我曾是一個海淘平臺的產品負責人。一年前，我想給這個世界留下點自己的作品，于是辭職眾籌開始做「the App」。眾籌的錢并不夠我請一個完整的開發團隊，幫我忙的幾位朋友除了一名是專業測試之外，其他人并不是業內人士。于是，擺在我面前的只有一條路，那就是：代碼外包，其它所有工作都由我來負責。

一年之后，「the App」上線了，它和我想象中一模一樣，沒有1px或1個邏輯的誤差。雖然它存在一兩個開發時沒想到的毛病，還需要繼續迭代，但是它入選了“最美應用”年度Top100，也拿到了不錯的用戶量，它在理念、邏輯、顏值上，都可以算是一個精品應用。

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

如果你是一名有志于開發理想中的產品的創業者，這篇文章將會告訴你很多的細節；而如果你是一名產品經理，這篇文章會從一名創業者的眼光帶你重新看待產品開發這件事，這里不再有PM和程序員、設計師之間的矛盾，只有純粹地追求做一個好產品，并為之付出自己的一切。

一、產品定位/需求分析：解決一個問題就夠了

一個產品能解決好一個問題就夠了，也許你會說，成功的產品需要“生態”和“盈利模式”。我只能說，除非你產品的核心功能本來就是去實現某種交易（例如p2p金融），或是致力于開發某種消費的沖動（例如“免費”手游），否則，生態和盈利模式都是建立在“最重要的那個問題已解決”的基礎上的。

高屋建瓴一上來就要搞什么生態的App往往是認準了一個風口，恨不得把所有功能都加上去，BP上能畫100個分析圖，然而基本功能卻做不到位，于是大多都被市場淘汰了。一個App的99%的營收也許都來自于它的附加功能，然而如果我們不把99%的力氣花在那不起眼的、只占營收1%的核心功能上，這件事就會很尷尬。

微信的核心

以微信為例，不論微信迭代多少個版本，它始終是一開始那個“取代手機發短信功能”的App（也許你已經忘了，以前人與人之間是用短信來溝通的）。第一欄和第二欄永遠是消息列表和通訊錄，就算朋友圈是中國最大的社交圈子，游戲欄目是中國最大的手游流量入口，它們都不可能突然跳出來影響你的日常使用?！叭恕庇肋h是通訊的主體，即使后來出現了公眾號和應用號，它們也永遠是被收納在一個次級入口之中。

而當你打開一個具體的對話，它的核心永遠是文字之間的交流，因為這才是“取代手機短信”的體現。哪怕是后來推出了劃時代的“語音”，發送語音的按鈕也永遠是在發送文字的旁邊，而語音的氣泡也永遠不會出現很多人要求的“暫停”或“后退”（除非未來微信推出插件式功能），因為聊天氣泡的主體永遠是文字氣泡，其它所有類型的氣泡，不管是現在的圖片、鏈接、視頻，還是未來的VR對話甚至是腦電波交流，它們在交互上都永遠不能凌駕于“文字氣泡”之上——除非文字已經不再是人類的第一遠程交流方式。哪天我們能像三體星人那樣用光的波長和頻率來交流了，微信的這個最核心結構才會改變，否則它就是走向庸俗，然后走向墮落。

「the?App」希望解決的唯一問題是：“這個世界上大多數人有動力去改變自己，然而他們沒有一套行之有效的方法來堅持正確的人生信念”。這個問題可以拆分成以下3種現象，每個現象都對「the App」提出了1個必須做到的要求。

1、我們一面收集人生觀，一面又在遺忘

當你看到一本好書，你會把那些醍醐灌頂的句子摘抄下來，貼在書桌前，現在那張紙肯定早就不見了；當你在朋友圈看到一篇好文章，你會立刻收藏下來，但你從來不會回頭去看；有時你突然頓悟，覺得從今天起就能重獲新生，但你一個月之后就變回老樣子了……

——這要求「the App」必須是一個能快速記錄，又能妥善保存的筆記工具。

2、我們總在一個人生問題上重復糾結，無法做到不斷升華

例如，你的缺點是習慣向別人妥協，不能維持自己的底線。從小到大，你受到過很多次大的傷害，每次你都痛徹心扉，決定從明天起不再做個老好人。然而這么多年過去了，你對如何“不做老好人”并沒有什么更深入的經驗，因為每次你的實踐周期都只有幾天，然后就把它忘得影都沒了，重新變成那個老好人，直到下一次重大挫折的到來。

——這要求「the App」必須是一個有效的知識整理軟件，能把不同時期記錄下來的，所有關于同一個人生道理的文字都匯集起來，并且給到你一種取其精華的整理方式，讓你對這個道理的認識能不斷升華。

3、由于人的劣根性，我們總在不同的人生觀之間搖擺

人的本性是趨利避害，在一個浮躁的社會染缸里，我們很難頂住誘惑，去堅持一個不變的人生哲學。

去年你拜訪了一個高僧，他告訴你要以德報怨，你激動得差點要去做居士；半年前你換了公司，你上司整天給你穿小鞋，你決定要做一個“厚黑”的人來保護自己；三個月前你看了一篇心靈雞湯，講了一個窮孩子兜揣10元錢最終成為澳門賭王的勵志故事，你決定不再計較當下困擾，無條件提升自己的實力和境界；這一周你又煲完了《紙牌屋》，于是決定要做男主角那樣能玩轉辦公室政治的人。你的人生觀一直在搖擺，然而卻鮮有成果，因為你很少在一個不動搖的人生方向上付出持續的努力。

——這要求「the App」必須擁有一套價值衡量體系，能精準地衡量不同人生觀之間的優劣，幫用戶淘汰掉那些劣質的心靈雞湯和錯誤價值觀，找到那個（或若干個）對自己最重要的人生方向，每天提醒自己來堅持。

我會用眾籌資金的90%來解決這個唯一的問題。思索這個問題貫穿著「the App」開發的頭和尾，也將延續到未來每個版本。每當我認為產品設計已經能完美解決問題時，過不了多久，我總會發現，我給產品增加了不少額外的功能，企圖用它們來滿足主要功能在智慧上的欠缺。

但最有效的問題解決方案永遠是一條單一的路徑，如果這條路上還有一些小岔路，只證明我還沒有找到最優的辦法。就像相對論把萬有引力統一了進來，M理論貌似也能把幾種弦理論、相對論和量子力學統一進來，科學家一直在尋找用最簡單的一個理論來概括宇宙所有的原理。從上帝或文明高度發展的外星人來看，也許我們的這種追求很渺小，還有太長的路要走，但這個過程本身就是一種嘉獎。

二、產品立項：拒絕數學公式，用感性來立項

App要解決的問題已經擺在這里，接下來就是給產品設計一個大概的框架。按照套路，我應該先把產品需要的功能全都列出來，然后再把它們轉化成干巴巴的、沒有任何藝術感染力的原型設計圖，這樣做的問題在于，直到產品的UI設計圖出爐之前，我沒法用眼睛去真實地看到產品是個什么樣子，我沒法對它產生一個主觀的感受。

人都是感覺的動物，一個人依賴一個產品，往往是因為他愛這個產品，而不是因為他需要這個產品（除非你做的是剛需產品，而且沒有競爭對手，例如12306；或者你壟斷了市場，例如淘寶），那么這些干巴巴的設計方案又怎能幫助我把握好產品的感覺呢？

我曾經去某個大公司的UGC新平臺應聘產品經理，我提前去他們平臺看了看，網站設計得很糟糕，讓人沒有閱讀的欲望；明明是一個重度依賴用戶原創內容的社區，然而各種困難的交互與產品中滲透出的強調權威的價值觀讓人沒有創作的動力。于是，在重新規劃框架之余，我詳細地指出了每個頁面的問題，把理想中的頁面做成了效果圖，希望讓他們明白，我們要營造什么樣的感覺才能讓用戶愛上它。

然而，當我跟他們的產品總監交談時，他對這些視覺化的方案完全沒有“感覺”，只是在一味地向我追問“用戶畫像”、“運營策略”這些比郁金香泡沫還要虛的東西，這場經歷讓我更加確信：一個不愛用戶，不極力給產品營造“感覺”，試圖用數學公式來推導產品設計的PM是永遠沒法做出有魅力的產品的。

每個人心中都有一片“信念”的森林

上圖是我最開始設想的，也是最有魅力的場景概念。在這個概念下，產品設計極其簡單，每個人的內心都是一片草原，當你進入我的App，我就給你呈現你內心的草原。你在生活中收集每一段感受，都是在這個草原上種一棵小樹苗。每天你都能領到一些水，你用這些水去灌溉那些你認為最好的樹苗。隨著你度過的每一天，有些樹木因為長期得不到水源而枯死了（草原的降雨量通常不足以支撐樹木的成長，這是有科學依據的哼），那么這些枯樹就會被送到樹木墳場，提醒你再也不要相信這些虛偽的心靈雞湯。而在你的草原上，總會有某些樹苗長得比其它的都快，它們變成了蒼天大樹，提醒你在它的指引下面對每天的生活。

Unity市場的3D資源千差萬別

感性過后，就要回到專業的角度去衡量它的可行性。這個方案一共有兩種執行辦法：3D和2D。經過跟以前做游戲的同事探討，3D最可行的方式是Unity 3D，然而當我花了一兩周時間了解Unity之后，我發現，直接在Unity市場買來的模型并不能拼湊出一個和諧的場景，因為不同模型的貼圖風格、面數、骨骼、動作都有很大的差異（如上圖），我需要一個既有很強的原畫功底以便能修改貼圖，又會改模型和調動作的資深3D設計師才能把所有買來的素材統一化。而在程序方面，找到一個精通Unity且熟悉手機適配的C#工程師，其耗費的錢財和難度都遠遠高于去找一個制作原生iOS App的資深工程師。所以這個方案已經遠遠超出了預算。

用分層動畫來實現透視效果

而如果采用2D的方案，草原作為主場景實現起來并不困難，如上圖，場景從近到遠分成若干個圖層，最近的前景（小草、雜石等）尺寸最長，而最遠的天空背景尺寸最短。在iOS前端，我們只需要定義一條規則：滑到最左邊時，所有的圖層都靠在屏幕最左邊；滑到最右邊時，所有的圖層都靠在最右邊。那么自然地，當用戶滑動屏幕時，他會發現前景滑動得很快，而背景滑動得很慢，不同的圖層都有不同的速度，于是就形成了透視的感覺。

場景是很好解決，那么物件是不是也很簡單呢？我們的最主要物件是“樹”，也就是用戶撰寫的某個人生道理。為了確定“樹”要怎么做，首先我得確定這個“樹”包括哪些元素、操作以及它們以何種組織方式來呈現。

“樹”應該是某種人生道理的集合

首先，如上圖，我的App不可能設計成用戶寫的每一篇文字都算作一棵樹。因為這個App的其中一個核心特點就是避免像日記或筆記應用那樣：你收集了大量的文字，卻發現很多文字講的是同一個人生道理。我們必須把相同的人生道理歸納在一起，讓它們組成同一棵樹。例如，如果你收集了8篇文章，講的都是關于“怎樣利用好自己的內向性格”這個話題，顯然它們應該放進同一個樹里，而不是每次閱讀他們都要去找到8顆不同的樹。

在一顆樹上，我不可能把這8篇文章設計成8個葉子。因為葉子要放在樹枝上，8個葉子倒容易呈現，如果別人寫100篇文章呢？我難道顯示100個葉子和相對應的100根樹枝？就算可以這樣做，那么這100根樹枝的組合必須符合樹的生長規律，否則看起來就變成了反人類，這算法的編寫和UI的重構又要耗費多少Manday呢？其次，樹的高度取決于你給它澆過多少次水，而不取決于它有多少個樹葉，那么顯然，一個很矮的小樹苗上長著100根樹枝的情況是無法讓我接受的。所以，我只能把具體的文章入口呈現為浮窗的列表里，點擊某棵樹之前，你頂多知道這棵樹包括多少篇內容，但具體內容列表需要你點擊之后彈出浮窗才能看到。

2D所需的美術資源是超限的

上面關于“樹葉”、“樹枝”的思考其實是不需要的，因為它們都被一票否決了，只要你看看上圖就明白了。一棵樹會隨著澆水次數的增加而不斷長大，如果是3D模型，我們可以把樹分解成幾個組成部分，然后給樹木定義成幾個階段，每個階段都設計一套隨機算法來組合成符合這個年齡段特征的樹木，在一個階段內讓樹的零件數量與模型大小、貼圖在兩個端點之間平滑漸變就行了。然而這里是2D的樹，不論是樹干、樹枝還是樹葉，你都無法直接拉伸它們，因為這樣帶來的視覺效果會違背自然。那么我只能給樹木做大量的實體圖片，也許是10個、100個、1000個，這顯然是非常愚蠢的方案，它導致的木桶效應意味著2D方案的破產。

那么我為什么還要提到關于“樹枝”和“樹葉”的思考呢？因為對這個細節的思考最終改變了「the App」的核心設計?！竧he App」最終版本確定下來的原型設計，是從一次又一次失敗的設計里提取出來的亮點組合而成的，而不是走流程走出來的。我想向你表達的是，如果你是一名PM，你的上司和團隊要求你先設計原型，請你明白，他們并不一定是正確的。

你應該盡量避免那么早進入原型設計的階段，原型設計牽扯太多全局性的東西，很多時候一個漏洞就意味著整個原型設計的報廢。除非你并不在意這個App是否完美，否則，在進入正式設計前，請你多開腦洞，多去思考一些關鍵性的細節，并且跟開發、設計團隊去討論它們的可行性以及實現的代價，這樣，你和你的團隊都可以少走很多彎路。

你更愿意下載哪個App？

上面提到的3D和2D方案，它們的出發點都相同，那就是一個具有感染力的情景是最能打動用戶的。例如左圖這款風靡Appstore很久的時間管理軟件Forest，右圖是我把它遷移到一個普通界面后的效果，左右兩個App功能完全相同，但如果它是右圖這樣的界面，你還有沖動去購買它嗎？把產品的主線功能巧妙地融入一個情景之中，用App來打造這個情景，用這個情景的感染力來給用戶洗腦，我至今仍然認為這將是成功速度最快的方案。

那既然沒有成本去做這件事，除了“情境化”之外，我手上的選項就只剩一個“專業化”了。我決定把「the App」打造成一個邏輯清晰、功能齊全、所有操作完美契合的專業化工具。產品的Point不再是“用情景給用戶洗腦”，而是用專業化的工具設計來強調自己是這個細分市場上的不二選擇，也就是強調細分的競爭力。雖然身邊的人總提到我的競爭對手是日記類App、記事類App和個人管理App，但如果我在“自我成長”這個細分領域做到足夠的專業性，那么我也就不存在什么競爭對手了。

專業性意味著一切，如果支付寶手機版能做好自己在“手機支付”這一塊的專業性，那么當微信去做紅包的時候，它就不會沒有主見地采取跟隨戰略，而是早就忙著布局移動支付了。這導致的結局是，我身邊便利店的手機支付大多都是微信這個支付領域的門外漢來普及的。

當一個產品永遠只關注怎樣把自己的核心訴求做得更棒的時候，它就能保持自己的競爭力；而當一個產品不看自己，總在看各種競爭對手和假想敵的時候，它就會心態爆炸，做事沒有主次，以至于迷失自我。

擁有酷炫交互的Paper 51

既然定好了要做專業化的工具，那么我就去找參照。從我下載的眾多App中，我發現了Paper 51，這是個了不起的參照樣本，因為它不光能像便簽、日記那樣快速寫東西，而且用戶寫的每條內容都是一片紙，這些紙張能自由拖拽，堆疊在一起，形成一個個紙堆——沒有比這更直觀的文字整理方式了（很遺憾，上圖并沒有展示紙張堆疊起來的效果，因為在截圖時我發現，新版Paper51已經放棄了這個設計）。

而從視覺上來講，Paper 51作為一個工具化的App有著了不起的交互效果，而這些效果竟然都是簡單的2D切圖構成的，這從成本上非常符合「the App」的開發思路——只要我能把2D切圖、適配方案和交互設計做到完美，那么只靠一名原生iOS工程師就能把「the App」做出和Paper 51一樣絢麗的視覺效果。

現在唯一不確定的是“紙張拖拽”的開發代價，我詢問過我的外包合作者智超，智超也不確定紙張拖拽到底好不好做、會出現多少Bug。對待這個問題，其實解決方案很簡單，那就是劃清界限，讓拖拽功能變成一個附加的功能，它的存在或去除并不影響這個App的其它模塊。一方面，我們先做出一個沒有拖拽功能的App，先上線再說；而另一方面，什么時候我們有閑余資金去開發拖拽功能了，它能作為一個單獨的模塊加到App里面，并不影響原有的布局。之所以這樣考慮，是因為“拖拽”本身就是一個快捷操作，快捷操作的本質在于它是一個“捷徑”，它只是“主要路徑”的腳本化，它們都可以用“執行已有功能1+執行已有用能2……”這種句式來表達。

確定了「the App」的主要視覺元素是“紙”和“紙堆”之后，那么接下來就是思考怎樣用這幾個素材來解決上個章節提到的那3個要求，這樣我就能給產品立項，以便開始具體的工作了。

第1個要求：「the App」必須是一個能快速記錄和妥善保存的筆記工具

從目前iPhone的特性來看，在我不聯通Siri也不跟其它App互通接口的情況下，快速記錄最少的步驟包括：

1. 單擊打開App。
2. 輸入文字或粘貼文字。
3. 單擊保存。

但如果打開App默認就能直接輸入文字，那么就意味著App啟動的默認畫面是輸入界面，這樣當用戶不是想輸入文字，而是想查看內容時，就要多一個退出的操作，這顯然是反人類的設計。而如果換種思路，在首頁常備一個輸入框體，那么，假設這個輸入框體在啟動時默認就處于激活狀態，那么鍵盤也會默認存在，不想寫東西的用戶照樣多了一個退出的步驟；假設這個輸入框體的默認狀態是不激活，那么當用戶要寫東西時，一樣需要一次點擊操作才能激活這個輸入框，從操作上來講并沒有節省一個步驟。

快速記錄的最簡步驟

綜上所述，必須在步驟1和2之間加上一個“點擊撰寫新文字”的步驟，這樣App才能獲得最好的交互體驗。最終得到的結論是，首頁必須常駐一個空白的紙，點擊或拖拽這張紙，就能立馬寫東西，然后單擊保存就能回到主界面（如上圖步驟）。

人生道理的整理過程

第2個要求：「the App」能把關于同一個人生道理的記錄整合到一起，然后讓用戶取其精華

這就要求「the App」在用戶不那么忙的時候，能呈現用戶記錄的所有臨時的紙張，用戶從里面挑選那些相同的人生道理，把它們合并起來。這個過程是多次且可逆的，當用戶覺得某篇文字實際上并不屬于某個人生道理，他可以隨時把這張紙從紙堆里抽出來；當用戶某一天又收集了一篇新的人生感悟，他隨時能把這張紙加入一個已存在的紙堆里。就像上圖所示的那樣。

不斷提煉和升華自己的人生觀

當用戶形成了一個紙堆之后，他能隨時去橫向比較其中不同紙張的優劣，把那些過時或不夠好的觀點淘汰掉，精簡這個紙堆。例如，小明最近發現自己最大的問題在于“擔心沒發生的事情”，他經常寫一些關于這方面的感想，也經常收集一些知乎、壹心理、朋友圈、書籍上的有用文章，并且把它們都整理到了同一個紙堆里。隨著他在生活中用實踐來克服這個問題，他對這個問題的理解就越來越深刻，那么他就可以定期回到這個紙堆，淘汰掉那些不夠深刻的文字，只保留對自己最有幫助的文字。同時，這個過程中也伴隨著會發現一些超越這個話題的存在，那么小明這時就可以去為它開辟一個新的人生道理。就像上圖所示的那樣。

形成人生觀的“排行榜”

第3個要求：「the App」必須設計一套嚴謹而方便的流程

只要每天堅持使用，那么用戶就能自然而然地完成對他記錄的每一條人生信念的“定價”。對于那些讓自己在生活中摔跟頭的劣質心靈雞湯或是錯誤人生觀，「the App」會協助用戶給它一個越來越低的“定價”，提醒用戶把這個人生觀“拉黑”，在未來整個人生中都不要去重蹈覆轍；而對于那些不易堅持卻對人生最有長期效果的正品價值觀，「the App」會協助用戶給它越來越高的“定價”，直至形成每個人的“核心人生觀排行榜”，堅守那些少數的，實踐證明最有效的人生觀，就能保證心靈的高速成長（如上圖）。

這第3個要求是最難實現的，它并沒有在立項之初就找到最好的設計，在后面的“虛擬迭代”章節，你將看到它詳細的誕生過程。

三、概念圖/交互設計：直接開始設計App的門面

確定好產品大致框架之后，我依然沒有開始做原型，而是直接著手設計App的首頁——既然我選擇了Paper 51做視覺參照，我就必須先眼見為實，確定這樣真的能做出一個視覺效果達到并超過Paper 51的App。首頁的視覺也會反過來影響到原型的設計，在線框圖里看上去很有條理的首頁原型，做成最終的效果并不一定能達到我要求的美感，這就會導致我設計的某些流程將連鎖地報廢，所以最保險的方案就是先把首頁的視覺確定到9成。

首先是美術風格的確立。由于已經放棄了3D，或是用2D分層動畫來實現偽3D，那我只剩3個選項：扁平、矢量風格和擬物。首先排除扁平風格，因為我們的設計元素都要圍繞著“紙”，而扁平化最不擅長表現的就是實體感。Paper 51用的是簡潔的矢量風格，但它有我們所不具備的拖拽交互方式，這種交互方式給人帶來很強烈的物理感，彌補了矢量風格的不足。所以，為了超越Paper 51的視覺，我唯有選擇擬物。

我第一眼就愛上的背景圖

確定了擬物風格之后，我就開始找背景圖，我花了十多個小時去圖庫里找素材，但當我看到負責測試的穎爺手上的錘子手機壁紙時（上圖左），我立馬就認為非它莫屬了。老羅是個尊重藝術家的人，錘子系統的每一張壁紙都標注了作者，于是我順利地在Depositphotos搜到了這張原圖（「the App」所有設計素材都是正版購買的）。原圖是大白天的光環境，而「the App」的風格應該是安靜和隱私的，我希望給用戶營造一種無人打擾的地下車庫的感覺，在這里，他可以向這面墻壁傾訴任何內心深處的事，所以我把這張圖處理成了黑夜的光環境（上圖右）。

首頁擺放的肯定是入口級的東西，那么顯然就要先設計“紙堆”。Paper 51的紙堆是用算法自動地把它所包含的紙張堆疊起來，比如說，如果這個紙堆含有3張紙，那么就顯示3張紙堆疊而成的樣子。但是在制作效果圖的時候我發現，「the App」的紙張是擬物的，如果只有一個“紙”的素材，僅靠隨機角度來堆疊，就會失去真實感，必須設計幾張不同的紙來隨機顯示；另外，紙張的陰影并不能像矢量圖那樣直接運算生成，必須手繪才顯得真實，而手繪陰影帶來的問題就是，這個陰影的投射將不受控制：紙張A在紙張B的上面，它的陰影只應該投射在紙張B上，不應該投射在墻壁和紙張C上，這就要求紙張A在投影時必須以紙張B的輪廓作為遮罩區，因此實現起來會耗費大量Manday。

設計“紙堆”，初步形成首頁

所以，最終我“偷懶”地給“紙堆”直接設計了一個整體的切圖（上圖左），而由于背景墻的頂部有個吊燈，所以這些紙堆只能放在屏幕中間，列表的滑動方式也只能是橫向滑動，加上肯定要放在底部才能用起來順手的“新增”按鈕，首頁的布局基本就確定下來了（上圖右）。

實現真實的光照效果

最讓我興奮的是我發現了如何讓整個首頁突破靜態PNG切圖擬物的局限，達到真實光照效果的辦法。我用通道+筆刷做了一個半透明的陰影覆蓋層（上圖中間），放在場景圖層的最頂部。這樣，滑動到屏幕兩端的紙堆就會逐漸被陰影所吞噬，而中間不受陰影層所影響的部分，在對比之下看起來就像是被吊燈照亮了（上圖右）。

用“開關燈”進一步強化光影

最后，我想著，既然強調了光影的變化，不如再做極致一些吧。于是我花了一兩天的時間，給首頁設計了開/關燈的交互效果?！竧he App」在未來很多用戶的手上是個很隱私的東西，沒人愿意在「the App」里寫上“我很懦弱，從今天開始我要采用××辦法改變這個現狀”然后被其他人隨意翻閱。所以，關燈的狀態剛好可以做成鎖定界面，如果用戶設置了密碼，那么這個界面就會顯示密碼盤，解鎖之后才能開燈。

開/關燈對適配來講是一個比較繁瑣的過程，我的辦法是，首先在PS設計稿里把所有圖層重新整理一遍，變成最精簡的結構。然后從這個圖層結構中去思考：我們在App需要把圖層分成幾個大組，才能最方便地實現開關燈的效果，而且能有最高的擴展性，隨時能加進去新的按鈕或內容。

提煉出首頁的4個UI大組

于是，如上圖，我整理出了從下到上的：背景、內容、壓蓋、懸浮，這四個大組。開關燈能通過這些大組的UI響應來實現，后續要加進去什么內容或按鈕，也能根據它的特點來加到“內容”或“懸浮”這兩個組里，因為從情境上來說，所有真實擬物的按鈕或入口，都應該加在“內容”這個組里，這個組在“光影”組的下層，所以會受到光影的影響，看起來就能跟整個場景融為一體；而所有附加功能的按鈕或入口，都應該放在“懸浮”這個組里，這個組的內容會漂浮在整個空間之上，不受光影的影響，以強調它們是超越這個空間的，獨立的存在。

最后，用表格的方式來標注它們的排列順序，以及顯示/隱藏的細則（實際上，從開發來講，這就是規范了每個UI組對于開/關燈“廣播”所響應的“態”），然后再標準化所有切圖文件的命名，這樣，在整理首頁交互思路之余，開關燈效果的文檔也就順便做好了。

四、原型設計/文檔撰寫：用避免“反人類”的方法來設計原型

我之所以強調設計原型的方法不要“反人類”，是因為我見過很多人設計原型的方法的確是反人類的（至少在我看來覺得很心痛，也許他們有自己的思維方式這也說不準），這里的“反人類”包括兩方面，一個是違背你自己設計原型的最佳思考方式，另一個則是違背程序員開發的工作方式。

Axure是我見過的最反人類且最普遍的原型設計方式，之所以說是“設計方式”而非“工具”，是因為它有它作為一個工具的合理性（例如，用它來說服投資方、不懂產品的上司，設計交互，在原型完成之后做定稿，或進行虛擬迭代），但如果用它來從零設計原型，我覺得這種行為就像是用十字螺絲刀來擰一個內五角螺絲——心累。首先我講講Axure原型從程序員開發的角度來看為何反人類：

Axure原型跟直接截圖沒區別

假設這張瀑布流效果頁是產品經理（或交互設計師）用Axure做給前端工程師的。它很美，沒錯，然而這跟你直接去其它網站截個圖給程序員，然后說“照這樣做”沒什么太大區別，實際上這張圖本來就是瀑布流鼻祖Pinterest的截圖。

（1/2）用Visio定義瀑布流的“零件”

用Visio做就不同了，見上圖，首先來定義瀑布流的單個“零件”。實際上還有一些圖中沒有說清楚的細節，例如文字位如果超過5行要怎樣設計“展開”方式，以及整個“零件”的熱區構成……這里只是大致的示例。

（2/2）用Visio定義瀑布流的布局

接著用第二張圖來定義布局（上圖）。同樣這只是個示意，很多細節沒辦法寫出來，且只局限于前端，但意思已經表達清楚了。當你拿著這兩張圖，配上UI設計師做出來的UI說明圖、切圖，前端（或重構）工程師就能很輕松地一次性交給你想象中的頁面，也無需你那么辛苦地跟進工作。原型設計最有效的方式并不是去“直接呈現你想要的東西”，而是“用模塊來重組產品，用最抽象的方式來概括全部的細節”。

而對于設計原型的人而言，Axure同樣是反人類的，因為它違背了正常人類的思維過程。為什么很多人私底下講話妙語連珠，大會上卻變成口吃？因為私底下這些人講話是“發散”的，想到什么就說什么，信手拈來；但是在大會上，他們不敢這樣隨意講話，把嘴邊的靈感都咽了下去，硬生生地用一些高大上的“首先呢”、“其次呢”、“第一點”、“既要……又要”這種句型來套路自己，把自己套路成了啞巴，這種扼殺靈感的思維方式就是“歸納”的。

Axure的使用方法就是“歸納”的，當你用它設計原型時，你就很容易變成思維上的“口吃”。它一上來就要求你做一個頁面，緊接著做下一個，緊接著就要確定這兩個頁面之間的關聯。但事實上，頁面、模塊和鏈接的成型是一個反復試錯的過程，在Axure里，你一旦做出幾十個頁面，再想變動其中的大模塊就太難了，約等于重做。它讓你喪失了不斷推翻自己原型設計的勇氣，變得害怕靈感。

而用Visio設計原型則能做到“發散”和“歸納”自由切換，用它做原型時，我能像個精神分裂患者一樣，一會切換成磕了藥的藝術家狀態，在畫布上隨意涂鴉我的靈感；一會又能切換成有點精神潔癖的理科男狀態，給剛才那個人收拾戰場，把那些亂七八糟的靈感整理成規整的文書——做原型最好的方式就是精神分裂。

自由繪制靈感草圖

見上圖，實際上，初期階段的原型比上圖的要復雜很多倍，到處都是密密麻麻的靈感和連線。這里為了你看得清上面的字，我就把它簡化了一下。每當我想到一個新點子，我只需要畫一個方塊，然后在方塊里寫上幾句話用來備忘；當我想細化它時，我就把這個方塊做成一個稍微詳細一點的頁面，然后用箭頭把它連接到某個地方。

我無需站在多么宏觀的角度去思考要怎么設計頁面，我只是盯著這個畫布，一遍又一遍地假設我是用戶，順著箭頭走，看看到了哪一步會遇到什么問題，被什么東西卡住，或是需要什么新的功能。做Visio原型是我在整個「the App」開發中最享受的一個環節，我會聽著FreeTEMPO喝著咖啡來做這件事，可惜它占整個開發的時間并不長，只怪它效率太高了。

輕松調整流程

如果你用的是Axure，當你流程設計有問題時，你需要把所有關于這一步的入口、出口都修改掉，隨著原型詳細度不斷增加，可能每一次修改都會耗費你幾十分鐘甚至一天的勞動。然而在Visio設計圖中，一切都是二維展開的，你需要修改的功能，有什么箭頭指向它，以及它的箭頭指向哪些模塊，一切都一目了然，只需拖動幾下鼠標就能調整整個流程，一次大改動一般只耗費幾分鐘的時間。

做原型最緊要的就是得比它高一個維度，四維空間（空間4維，不是3維空間+1維時間）的人看人類，五臟六腑都是展開的，所以看你一眼就知道你昨晚吃了什么。目前人類的App都是二維的，做在Axure里，你也只能困在那個二維空間里去探索，但做在Visio里，你就能一眼看到它的全局，因為在某個維度中去看低一個維度的東西，它就是展開的。

初具規模的App原型

一眨眼，整個原型變成了上圖的樣子（上圖只是案發現場還原，因為當時的原型已經直接被繼續細化了），一個有大概流程的原型稿。你可以注意到，原型已經被若干個灰色的“容器”分割成了幾塊，這樣做的原因在于，當你開始細化某個模塊時，它的內容就會越來越多，內部的箭頭和連接線也越來越多，如果不用容器裝起來，那么內部、外部的連接就會混雜起來，讓你難以專注。

在專心設計某個容器內部的功能時，我通常會把整個容器拖開老遠，跟其它部分完全隔離開，以便我能不被其它模塊分心。在這個階段，由于畫布已經被撐得很大，所以我強烈建議你買一個帶有橫向滾輪的鼠標，Visio沒有類似于PS的手型工具以便用來自由拖拽畫布（只能點擊鼠標中間來拖拽，但操作體驗不流暢），橫向滾輪+縱向滾輪可以描述任意一個二維空間向量，讓你在越來越大的原型畫布上自由沖浪。

用模塊來拆分原型

當原型設計到這一步的時候，整個格局已經大致確定下來，不再需要每天給它做大手術了。此時如果我繼續在一整張畫布上作圖，就會比較難受（卡頓，加上頻繁的縮放和跳轉），那么這時候就可以把原型根據模塊來分成若干個頁面。如上圖，首頁的原型被我單獨分成一個頁面，用5個橙色的方塊來代表箭頭對應的模塊，寫上“詳見××模塊”。

具體模塊之：閱讀模塊

見上圖，這是原型的其中一個具體模塊——“閱讀”模塊，你看到的這個示例是「the App」早期的一個原型，當時的設計跟現在的有所不同，但它挺適合用來體現模塊化思維。

（1/2）從后端而言，兩種閱讀內容是不平等的

如上圖，從后端來講，“感悟”包括“未淬火”和“已淬火”兩類，而“信念”則應該定義為：個數∈[1，限定額]的若干個“已淬火感悟”的“組”——它們并不是平等的。但前端設計上它們有很多類似的地方。

（2/2）從前端來看，兩者有很多共同點

如上圖，左邊是“感悟”的閱讀頁，右邊是“信念”的閱讀頁，它們閱讀區域、刪除、移動功能都是相近的，只不過是有一些細節的區別。

合并同類項

模塊化的設計思維也好，面向對象的開發思維也好，其實都是合并同類項。

在用Visio做原型時，當我發現這兩個頁面有很多類似的地方，我就用鼠標把它們拖到一起，然后試著合并同類項。如上圖，我把這兩個頁面的閱讀模塊擺到左右兩邊，把其中雷同的模塊隱掉，放到中間的黑色容器來統一描述，就像一個夾心餅干。前端工程師拿到這頁文檔，只要開發中間黑色的餡兒就行了。

用一個流程圖來表達兩個功能

而至于“刪除”功能就更簡單了，畫上一個流程圖，它就是一個直接能翻譯成代碼的狀態機。不管刪除的是感悟還是信念，實際上只是一開始走的支路不同，而且這些支路僅限于前端展示，當狀態機走到后端層面時，其實處理的邏輯都是完全一樣的。

上面列舉的這兩件事，是把“信念”和“感悟”在原型層面能看到的一些相同之處歸納起來，讓它們共享一些模塊，但這種抽象能不能更高級一些？我發現一個現象：雖然“信念”在概念上是“感悟”的組，它們級別不同，但是在整個原型中它們很多的處理邏輯都相同，例如：移動、列表展示、打孔……這是因為在視覺設計上，它們只是不同類型的“紙”，必然會有很多雷同的地方，所以，何不直接把它們劃分到一個“類”？

《黎明殺機》

一個很火的恐怖游戲《黎明殺機》最近出了個很大的BUG，各大平臺主播都在玩這個BUG，玩出了很多搞笑的效果。首先說下這個游戲是怎么玩的，很簡單，四個玩家扮演“逃生者”，一個玩家扮演“屠夫”。逃生者被屠夫抓住掛在樹上就會死，要順利逃出去你必須跟屠夫玩躲貓貓，偷偷修好5個發電機以便開啟逃生門逃走。

屠夫一共有6種，他們的能力都是固定的，分別是能在草叢里偷偷放捕獸夾來陰人的“夾子屠夫”；手里拿著電鋸，電鋸拉開就能高速沖到你面前的“電鋸屠夫”；敲一敲鈴鐺就能隱身的“小叮當”；喜歡在地上畫個圈圈詛咒別人的“李奶奶”；《月光光心慌慌》的男主角“殺人鬼”和擁有瞬移能力的“護士”。

而作為逃生者，他們手上可以拿一些道具，例如可以用來晃瞎屠夫幾秒鐘的手電筒，或是可以用來包扎傷口的急救包。

于是奇怪的事情發生了，有一天，某個國外玩家發現了一個BUG：通過鬼畜地在“屠夫”和“逃生者”兩個界面之間切換和點擊，“逃生者”手上竟然可以拿到“電鋸屠夫”的電鋸，而如果這個人被一個“夾子屠夫”殺死了，夾子屠夫竟然可以撿起這把電鋸，右鍵拉動電鋸就能像電鋸屠夫一樣以60km/h的速度沖刺鋸翻逃生者，還能拿到電鋸屠夫專有的“電鋸沖刺”獎勵分數。

雖然這個BUG很重大，不應該出現，但是從這里可以看到《黎明殺機》通過對“類”的精妙劃分而實現的高效開發（對于一個只有20人左右的小團隊，能制作出占據Steam榜首的PC游戲，高效是必須的）。從玩家角度來看，不同的屠夫的能力都是固定的，但是從這個BUG可以看出，實際上這個“能力”都是由道具所賦予的。

電鋸屠夫之所以拉電鋸可以沖刺，并不是因為這個屠夫比其它屠夫多了一些專有代碼，而是“電鋸”這個道具本身就能賦予一個屠夫“高速沖刺”的能力；電鋸沖刺的分數獎勵，也并不是由其它模塊來負責具體的計算，而是這個道具在使用時就會自動計算分數，然后把結算出來的分數“通知”給那個統一的計分模塊；而逃生者手上可以拿電鋸，屠夫可以像逃生者一樣從地上撿起它則說明，所有的道具，不論是逃生者的急救包還是屠夫的電鋸，它們都有很多共享的屬性，例如：可以被撿起來、可以裝備在手上、點右鍵可以發揮它的功能、屏幕左下角會用圖標顯示這個道具的狀態……

《黎明殺機》對“類”的劃分

如上圖，實際上，在《黎明殺機》中，所有的道具都有一個通用的模板，這個總的模板就是“父類”，在此基礎上細分下去，形成各有特點的屠夫和幸存者道具的“子類”，直到最后，變成實實在在的，某個具體的可以拿在手上的“對象”，例如工具箱和電鋸。

“類”：NOTE

回到「the App」原型設計，經過跟iOS開發者智超的討論，我們決定把“感悟”和“信念”設計成同一個叫做Note的“類”（上圖），有了這個類的劃分，我就能進一步去整合Visio原型中除了上面提到的“閱讀”和“刪除”之外的模塊了。

Visio原型制作完之后，我把它們轉移到OneNote之中，專門建立了一個描述“Note”的分區，按照類的結構來建立不同層級的頁面，然后把做好的Visio圖形粘貼到各個頁面里……其它的模塊也都用模塊化的思路整理到OneNote里，到了這一步，一個完整的App文檔就差不多搞定了。

同步這個OneNote文檔給程序員，給他們分配閱讀權限，我們就能協同工作了。「the App」除了設計素材都是正版購買之外，所有軟件也都是正版購買的，所以協同工作對我來講只是點一下“保存到云”。正版是一種生活方式，每個月我大概花500月費來供養我整個電腦的所有軟件和服務，這是愛的供養，這讓我從來不需要到處去找破解版軟件，我的電腦從不會中毒，我重裝電腦之后所有軟件的云端設置都會自動還原，我的所有資料也一直在付費云端增量更新，我從不擔心它們會丟失，每天我一打開電腦就能安心工作。

Onenote文檔中不光得有Visio原型，還需要很多的附加文檔，從性質上看，主要包括“宏”、“系統文檔”和“集中說明”。它們并不是我一開始就明白要去單獨做的，而是做原型的過程中，遇到了用Visio無法說清的問題，或是即使說清了，也會讓Visio圖形變得太過臃腫，于是就自然而然地想到要另起爐灶了。

（1/3）附加文檔：宏

（1）首先說“宏”

“宏”一般用來歸納那些App中零散出現的，但是不便于統一成某個模塊的東西。上圖是一個用來歸納「the App」中所有后期可能要變動的數值的Excel表格，例如，打孔器的冷卻時間是多少個小時？打一次孔的加分是多少？每個信念最多能容納的感悟數量是多少？……這些數值我無法一次確定下來，需要在試用過程中不斷調整，顯然，如果我今天在A文檔里去改數值α，明天在B文檔里去改數值β，我和智超之間至少有一個人會瘋掉的。

當我寫一個宏文檔，智超就會在代碼里寫一個宏，在這個宏里他就能直接修改這些數值，并能自動應用到所有關聯的代碼，只需要幾秒鐘就搞定了。而在后期測試的時候，我顯然不能像數值中要求的那樣：一個感悟寫下來之后，隔9小時才能淬火——我只有1分鐘的耐心。那么很簡單，我在表格中多加入一列“測試數值”，寫上“1分鐘”，到時要個測試版就行了。

（2/3）附加文檔：系統文檔

（2）“系統文檔”

Visio原型比較善于表達前端的流程或狀態機的邏輯，而如果你想要詳細闡述某個系統的原理就比較難了?！竧he App」中“文件夾”這個概念，在Visio中主要描述的是看得到的部分，而看不到的細節就要用Word文檔來描述了（上圖左），例如：文件夾是否可以重名？是否可以為空？兩個欄目的文件排序規則分別是什么？這些東西在Word文檔中用論文的結構可以很輕松地交代明白。

「the App」的文件夾都有封面，這些封面包括3種，第1種是特殊文件夾的固定封面（包括不設置封面時的默認代圖），第2種是用戶自己拍攝或導入照片，第3種是系統自帶的封面。那么這就帶來一些問題，例如：固定封面是否屬于系統自帶封面可供選擇？用戶自己拍攝的照片被替換掉之后，是否繼續保存？……

這些問題很難用簡潔的文字來概括，所以我做了一些“偽數據結構”（例如上圖右），雖然這個數據結構設計得很外行，直接采用可能會引起手機爆炸，但文檔的意義在于溝通，偽數據結構的表達方式在這里能用最少的廢話講清楚我要干什么，那么它就是最好的溝通方式。同理，你甚至可以用偽代碼的方式來描述一些文字不便形容的邏輯，只要程序員能輕松理解到跟你完全一樣的想法，何樂而不為呢？

（3/3）附加文檔：集中說明

最后一種情況是“集中說明”，顧名思義，「the App」中很多東西是零散的，不便于在主文檔中出現的。例如左圖歸納了App中所有出現的文本輸入窗口的具體屬性，包括它們的窗口名、初始文本……這樣我在原型中就不必列舉每個文本輸入頁面的具體屬性；再例如右圖歸納了App中所有教程的出現時機、地點、展現方式，同理，這些凌亂的東西根本不應該出現在主文檔不是嗎？

【未完待續……】

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

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