在產品的具體設計中，原型是怎麼來的呢？筆者認為原型由信息架構設計與條目設計組成，並以途家app搜索頁為例講解了條目設計。
幾千年來，哲學家們一直在思考三個問題：我是誰？我從哪裡來？我到哪裡去？對於設計師來說，我覺得同樣存在類似的三個問題：
這個產品有什麼價值？這個產品怎麼活下去？這個產品具體怎麼設計？這是三個很大的問題，就像幾千年來哲學家們還沒有想通的哲學三問一樣。作者今天就是想結合自己的理解和一個案例，針對上面第三個問題的一個分支說說自己的理解，即：在產品的具體設計中，原型是怎麼來的？
在進行產品設計之前，會有大量的市場調研和產品定位問題，再之後才是進行原型設計，開始產品初期的測試，繼而進行不斷的測試、迭代、完善。在我看來，原型會由兩部分設計生成，其一是信息架構設計，其二是條目設計。
一、首先說一下信息架構設計
1. 什麼是信息架構？
「信息架構」在百度百科中的解釋是：對某一特定內容裡的信息進行統籌、規劃、設計、安排等一系列有機處理的想法。
「信息架構」在我們設計層面是：指對某應用的功能、信息、導航進行規劃，包括該應用有多少層級，每個層級包括多少頁面，每個頁面裡包括多少個條目，每個條目裡要有多少功能元素要呈現以及每個元素的優先級排序。好的信息框架能讓用戶快速的尋找到自己想要的內容和功能，
例如產品中一級頁面有幾個、分別是什麼，每個一級頁面中又有什麼功能。如果你把一個產品的功能點按照層級用腦圖畫出來，那麼這就是這個產品的信息架構。途家app的信息框架圖：
2. 怎麼設計產品的信息架構呢？
按我的理解和市面上常見的做法，一般會把產品的核心功能放到首頁、也就是信息架構的頂級。把其他重要的功能放到一級頁面。依次按重要性進行信息架構層級的設計（當然也會因為產品方對某一業務的重視程度把他放到信息架構中更上級的地方，也就是推廣）。
這裡我曾經在聽純色老師的講座中提到過一個案例：微信的朋友圈功能其實和通訊錄或首頁的關聯性更強，因為是人的動態嘛，他和看一看、小程序、遊戲、購物等等明顯不應該處於信息架構的同一部分。那麼為什麼微信的朋友圈功能放到了發現頁面呢？
答案是朋友圈是一個明星功能，可能在使用頻率上僅次於聊天功能。把他放到發現頁面可以增大發現頁面中其他信息條目的曝光量，讓用戶更多的去使用購物功能、遊戲功能、看一看、小程序……等等其他功能。課件信息架構也並不是一成不變的按照分類和邏輯在設計的，需要結合業務目標靈活變通。
有的時候信息架構的設計還會出現一些冗餘設計，例如支付寶首頁中【掃一掃】功能是有兩個入口的，一個在頁面頂部直接露出，一個在加號裡。這樣的設計按作者初步來想的話是考慮到用戶在使用其他產品時的時候習慣，進而影響了本產品的設計。也就是我們常說的雅各布原理。
我們在確定了信息架構之後，頁面的層級和包含內容都已經確定了，下面要做的就是設計出每個具體的頁面，包含功能的優先級、按鈕位置、展示什麼信息等等。這就需要引出一個概念：條目。
二、條目
1. 條目是什麼呢？
條目是頁面中的可點擊單元，就像你現在看到了我寫的這篇短文，短文包含了標題、封面圖、作者名稱、摘要、發布時間、閱讀量、點讚量、等等這些信息組合在一起形成了一個信息單元，這個按照一定規則顯示的信息單元就是條目。如下圖紅框框起來的都是一個頁面中的條目。
2. 條目中的構成元素包括什麼？
條目的構成元素有：圖片，文字，圖標，標籤，圖形等。
以上圖「中間淘寶搜索頁面」中框起來的條目為例，列出該條目的構成元素：商品圖片+熱門商品的角標+天貓商鋪的標籤+標題+小標籤+價格+銷量+發貨地+店鋪+相似寶貝icon。
（註：一種條目會存在不同的幾種狀態，如淘寶第一條商品圖上有hot的角標，第二條商品圖上沒有角標，這就是兩種狀態）
3. 我們具體怎麼設計條目呢？
1）產品性質決定條目的設計
產品的性質決定了我們構建信息時要強化哪些信息。
以途家民宿app為例，我們使用途家app時，主要搜索挑選符合我們條件的民宿，如下圖是途家app的搜索結果頁兩種條目設計，都滿足了我們在這個頁面需求，選擇自己喜歡的房間同時關注價格和更加詳細的位置，哪種條目設計更好呢？
是第一個條目的設計比較好，因為我們進入這個頁面，最先關注房間的情況，第一個條目設計圖片比較大而且可以左右滑動查看更多關於房間的信息，省了一步用戶點擊進入情況頁查看圖片的步驟，所以民宿的特性就決定了我們在進行條目設計的時候，要強化圖片信息。
2）產品資源決定條目的設計
下圖左邊是36kr的首頁文章列表，資源豐富每天更新的文章比較多，注重用戶的閱讀效率，所以條目設計的比較小。
右側是初創公司的文章列表，文章資源有限，更新速度較慢，所以條目設計比較大，一屏展示2.5個條目，提高用戶的轉化率。
3）使用場景決定條目的設計
如下圖，分別為餓了麼「首頁上的商家推薦」和「搜索列表頁」兩者的條目結構，
「商家推薦」條目商家logo會很大，目的是為了用戶深刻記憶商家（logo圖形比文字更容易記憶）形成品牌效應；「搜索列表頁」用戶有明確目的的去搜索，所以食物的圖片會更加引起用戶的注意，這裡把商家logo做的小一些，主要突出食物圖片轉化用戶。
4）需要考慮到後期的擴展性，迭代過程中能夠承載更為複雜的信息與功能
如：初創項目第一個版本會功能條目比較簡單，這就需要我們在設計的初期，一定要考慮到後期迭代的內容，把條目設計的更具靈活性；
4. 原型設計的注意事項
多個條目信息組成高保真原型，我們在畫原型的時候，一定要注意：
儘量使用灰色文字，不要大面積使用彩色的文字，有色彩傾向會影響UI設計師對頁面的設計；做好交互規範，相同的功能要用一樣的樣式表達。當我們輸出高保真原型圖時，需要對照交互自查表，看自己的交互狀態，交互說明是否都寫全面，以免丟掉異常流程和特殊的內容狀態。（下圖是交互自查表，需要高清版的，在公眾號內回復「互動設計自查表」領取)
以上是我對【在產品的具體設計中，原型是怎麼來的？】這個問題的理解，是從信息架構和條目兩方面來說的，下面我們逆向來拆解一個產品中的真實條目案例，來看一看。
三、條目分析的案例——途家app搜索頁
途家slogan-全球酒店公寓和短租預定平臺
1. 條目狀態
a. 圖片+收藏icon+優選標籤+標題(顯示一行)+房屋住人情況+評分+點評+離搜索目的地的距離+房屋標籤（最多顯示5個）+價格+已減金額+描述信息+房東頭像+超讚房東icon。
b.圖片+收藏icon標題(顯示一行)+房屋住人情況+評分+點評+離搜索目的地的距離+房屋標籤（最多顯示5個）+價格+描述信息+房東頭像。
c. 入選標籤+圖片+收藏icon標題(顯示一行)+實拍信息+房屋住人情況+離搜索目的地的距離+房屋標籤（最多顯示5個）+價格+已減金額+描述信息+房東頭像。
2. 條目規則
a. 房屋圖片房東可上傳多張（我翻看多個條房源目猜，最少的圖片是7張，最多的是37張，所以我猜測最少要上傳5張，因為圖片輪播是5個，最多應該不限制）房東上傳的圖片需要官方審核通過；
b. 房屋信息除了圖片展示，還有VR和視頻模式；
c. 標題顯示一行，超出是標題文字+…顯示一行；
d. 價格顯示到個位；
e. 房東頭像必須上傳，分為超讚房東和普通房東；
f. 每個條目的大小是一致的，約佔屏幕的1/2。
3. 條目推薦機制
a. 第三行標籤最多顯示5個，根據房屋信息及用戶評價自動生成，前面的橘黃色標籤是根據房東填寫的房屋信息生成的，後邊灰色的是根據用戶評價自動生成的（猜測）。
b. 下拉滑動4個條目信息（2屏），會根據你的搜索情況，出現篩選條件，更加準確的推送信息；
c. 篩選條件後邊再滑動4個條目信息（2屏），還會根據你的情況，再次出現篩選條件；
以上是作者的一點點理解，歡迎大家補充指正~
本文由 @ 杜昭 原創發布於人人都是產品經理，未經許可，禁止轉載
題圖來自Unsplash，基於 CC0 協議