如何將需求落地到設計中？
謀全局者，才有自信謀一隅當設計師進入設計階段時，會出現典型的負隅糾結，而在產品整體框架和產品協同上缺少大局觀。往往在局部形成的設計優勢，在全局上不可用或不一致導致了優勢喪失。
拿一款閱讀與發布文章的產品來說，關於網站與app的同步問題，當我們從需求出發開始規劃設計時，我們談的是如何與網站打通進行無縫的閱讀與發布文章功能的對接。而當我們進入具體功能設計時，討論的更多的是鍵盤的自定義功能是哪些，上傳圖片數量限制，圖片文字編輯如何操作，產生什麼問題，怎麼解決。
討論到最後，發現我們已經完全聚焦在鍵盤的自定義上，更深度的聚焦在移動端APP編輯文章中存在的問題，以及解決的各種策略。隨著時間的流逝，我們已經不自覺的進入了極為細緻，極為縝密的深層交互定義和行為推演中。
往往是午飯回來後，相關設計人員才會突然意識到，好像在不同的模塊出現了一致性問題，出現了出口入口的流程方向問題，還出現了忽略網站協同，單純的在思考移動端深層行為問題…而產品在Q（質量）C（成本）T（時間）模型中如何權衡取捨，如何構建具有競爭力的模式，如何通過設計和運營變現，也因為被帶入深度的細節討論忽略了全局。
類似以上的案例，在網際網路行業隨時可能發生，那麼如何才能控制宏觀與微觀設計的切換自由度？
必備的工具如下：
1. 三大用戶工具
新手用戶、中間用戶、專家用戶
2. 用戶模型工具
比如有三種類型用戶，A類，B類，C類。A類用戶中新手用戶的場景和需求，可能的信息與行為；A類用戶中中間用戶的場景和需求，可能的信息與行為；A類用戶中專家用戶的場景和需求，可能的信息與行為；B、C類用戶以此類推。
3. 用戶心理模型工具
用戶心理模型是如何理解他要達到目標所需要的信息和行為的，你提供的信息與行為與他的預期需要針對性的匹配。
4. 框架工具
將已獲取的需求進行信息屬性上、或行為屬性上、或場景屬性上的分組歸納聚合，形成框架圖。
框架圖能夠讓你在已確認的需求上有組織的分類實施，並且能夠快速的看到獨立的需求末梢之間存在的內在業務關聯或場景關聯，進而影響你對設計方案行為的定義。使用框架圖也能夠在全局上提取出需要保持一致性的模塊（反過來說就是設計-視覺-代碼可以復用），同時也能夠從全局角度看到任務切換導致的各模塊間切換與協同。
5. 矩陣圖
涉及到複雜流程狀態或多用戶權限系統的，使用矩陣圖按照需求進行多維度的狀態(對應流程狀態)或權限(對應多用戶類別)進行歸納整理。
矩陣圖主要用於涉及到多用戶角色、屬性、權限的系統。當用戶角色和對應的用戶權限、用戶屬性出現網狀關係時，必須使用一種方法保證信息的可查閱性。當涉及到用戶權限時，經常會出現戛然而止或者主觀臆斷，需要的話，直接將矩陣圖列印出來，對著角色-權限-屬性進行查詢既可。如果有不合理的權限設置，隨時更新，保證整個團隊對於用戶角色-權限-屬性都能夠在可感知的狀態中。注意這些更新是全局聯動的，矩陣中一個權限或屬性的變更，都有可能引起全局多處的聯動更新，此時更需要全局觀和對矩陣的深度理解。
6. 流程圖
涉及到複雜流程的，需要將產品狀態+用戶行為梳理為流程圖，將用戶必然行為導致的產品狀態分化在流程圖體現出來，保障產品在各種狀態下的流程流向清晰可見。
如何將需求落地到設計中假設你接到一個具體需求：用戶需要買火車票，請幫助他。
你該怎麼將需求向設計落地？
首先第1個工具要發揮作用：買票的用戶是否存在新手、中間、專家用戶？12306已經幫助我們培養分化了這三類用戶。
接下來使用第2個工具用戶模型：
買票用戶分為A類：偶發需求產生的臨時性買票用戶；B類：長期不固定目的地出差的用戶；C類：長期固定出差相同目的地的用戶；D類……第3個用戶心理模型工具：（此處需要強烈依賴調研）將獲得的心理模型作為關鍵信息輸入到設計流程，用互動設計服務A、B、C類用戶提供準確的信息和行為。
第4個框架工具：將調研中獲取的用戶需求，從用戶模型中能看到三類模型在行為上的分化明顯，因此我們進行」行為屬性」上的歸納。
接下來，你要理解買火車票的業務，確認產品框架中重要的、高頻的需求集中在什麼任務中。不重要的，低頻的但不可捨棄的需求集中在什麼任務中，從而構建出產品的框架。
接著，確認好需求中的用戶成分是否涉及到多用戶、多權限矩陣。假設我們看到的是主體的C端用戶（因國情決定後臺票務數據唯一且不可私有化），那麼買票的需求自然聚焦於買票本身，而非用戶權限矩陣中。
接下來，我們針對買票需求進行需求落地，而配套服務和個人數據僅作為附屬數據，不作為本文討論的重點。
買票作為需求輸入後，我們在產品框架中看到了買票任務所需」信息」和」行為」，接下來即將進入我們進行需求落地的四部曲：需求——分析—拆解—篩選。
最終，我們看到的思路如下圖：
針對A、B、C三類用戶，將會對框架做如下分化：
通過對A、B、C三類人物模型針對性的做信息和行為匹配，我們看到產品需要滿足A類的基本信息和行為需求；同時也需要滿足B、C類用戶的場景化打包信息（包含行為）的需求。因此，產品框架需要體現的是基礎性的設計建設，保證A類用戶在任務流程的可用性上儘可能的達到100%的高度，而此處不必過分考慮A類用戶的使用效率(用戶需求偶發特點決定)，但必須考慮的是信息供應量的充足與信息出現時機的準確性，以保證A類小白用戶初次使用信息也能夠成功獲得車票、A類中間用戶長時間間隔後仍然能夠拉起這條冗長的任務流，A類型用戶基本不存在專家用戶，所以不要過度考慮了。
對於B、C類用戶，因為用戶的需求清晰明確，用戶行為所產生的數據可以作為設計決策和技術實現的依據，因此從集創堂槍型思維的角度來處理這兩類用戶需求，就需要對其所需信息和行為進行場景化打包處理，目的是篩選信息，提升用戶因行為數量（或頻率）上升而導致的對操任務效率的需求。
我們需要將篩選出來的需求向設計框架中落地，以移動端為例：在做移動端設計時，我們的基本素養是要知道移動端的頁面對象的構成，分別是：狀態欄、標題欄（或叫做導航欄）、內容區、標籤欄。
從需求的重要性和頻率兩個維度來衡量買票的需求，會將A、B、C類用戶「買票」需求定義在標籤欄中的頭屏位置中。
接下來，我們需要在買票需求中落入必選需求，從前文分析中，我們看到需求中包含了信息和行為。本質上，行為也是需要信息入口的，所以，信息本身又可劃分為展示信息和行為信息。
在布局信息和行為時，我們需要在行為層上來規劃信息布局。行為層上，用戶使用移動端基礎行為劃分為雙手操作和單手操作。而設計師手上必要的數據，便是考慮單雙手狀態下的手指操作行為的舒適區域數據。如下圖，我們看到用戶在不同的尺寸的屏幕上，單手操作舒適區和困難區有著顯著的變化，而我們如何決定使用什麼樣的屏幕進行上下適配，確定信息的布局儘可能落入舒適區？這裡的問題好像越來越多了……
首先我們要理清楚需要什麼樣的屏幕尺寸，再決定如何在內容區布局信息和行為。
為了滿足用戶需求，我們需要清晰的掌握用戶信息，所以用戶使用什麼移動端對我們來說至關重要。假設用戶90%使用的都是安卓端，那麼開發iOS版本意義不大，反之相同。這裡面涉及到的決策信息太多，暫不做詳細討論，我將在下一篇文章」如何做設計決策」中和大家交流。
看一下圖中移動端單手操作的數據，可以看到在右手單手持握時，隨著屏幕變大，舒適觸摸區在極速縮小。丟失掉的舒適觸摸區轉移到了伸展觸摸區和困難區中。而用戶在獲取信息過程中，對於信息的瀏覽順序是從左到右，從上到下。所以就構成了信息與行為的分布矩陣，如下圖所示。
iphone4-6Plus在單手觸摸區域上的測試總結，隨著屏幕變大，舒適觸摸區越來越小，而伸展區變大，困難區也急速變大。
信息重要度從左到右、從上到下遞減，操作的重要度從下到上遞減。因此我們需要將信息布局在內容區的左上位置，將行為布局在內容區的偏下方位置。
作為擁有信息和行為的雙重屬性的信息，優先歸納進入信息屬性中。考慮落入信息重要度高的「信息填充區」。
對於單純的行為，我們需喲啊考慮將其行為布局在「行為規劃區」中，以便用戶行為轉化過程中行為能夠落入屏幕的舒適觸摸區或伸展觸摸區
我們將信息必選項和行為必選項整理之後，結合觸摸區的區域，進行布局，優先布局信息（用戶第一時間需要），其次布局行為。
你來決定是時間重要還是地點重要，本例中，結合用戶已建立的使用習慣，決定將地點作為第一信息呈現。按照出發地、目的地的結構顯示信息。為了信息本身的屬性，我們布局在屏幕偏上的位置，這裡已經進入了屏幕的操作困難區，我們部分的犧牲了操作的舒適性來保障信息傳達的重要性。
其次，將時間和乘車人布局在伸展觸摸區，這裡有一點需要強調：時間的選擇頻率要遠大於地點和乘車人的選擇頻率。但從信息屬性的角度來決策，時間要大於乘車人，因此時間部分觸碰到了困難區，相對遠離了舒適觸摸區。最後，是必選行為，儘可能得出碰到舒適觸摸區。
有了初始化的框架之後，接下來需要收集任務，進行任務流程串的梳理。從上文方案中，我們看到用戶的行為包含
必選任務流程：
a設定出發地-目的地；b設定出發時間；c設定乘車人。可選任務流程：
設定車次；設定座位；設定價格區間；設定返程時間。接下來，我們隊必選任務流程進行流程串梳理。
示例：設定出發地/目的地任務流程
結合整理出來的流程圖，進行信息-行為的梳理，根據區域數據，進行信息和行為的布局。將流程中的所有節點，全部使用頁面承載展現出來，便將設計理論落地到了實踐當中。但是這只是基礎的設計能力。其中關於設計原則的把握還需要隨著項目經驗一步步的積累。
比如說，當前的設計是滿足了三類用戶中，A類對任務有效性最求最高，對效率無追求的用戶。那麼此時，作為資深的設計師，需要考慮的是場景化下的設計決策和布局。針對B、C類用戶，我們需要做什麼？他們一類是長期出差目的地不固定，一類是長期固定往返。
結合我們使用框架工具所梳理出來針對B、C類用戶的場景化打包
B類用戶的高頻次特徵，決定了他們對於購買流程效率的高需求。那麼如何提高他們走完購票流程節點的效率，是此處思考的重點。提高效率的具體方法有很多，包括數據的復用、信息預設、基於用戶行為數據的潛在行為預判等。
這裡可用的復用數據包括：用戶的歷史訂單、乘車人；預設信息包括：地理位置定位、訂票價格區間、位置喜好；基於用戶潛在行為的預判包括：訂票時間。因此，我們考慮到在滿足A類用戶的前提下，開始覆蓋B類用戶的需求。
注意：在覆蓋B類用戶是，我們對時間選擇控制項做了修改，並未使用iOS UIKit中提供的預定義功能控制項，這將會為研髮帶來定製的開發量。根據《iOS人機界面設計指南》中告知我們的信息：UIKit除了定義UI組件元素，還定義對象如何實現功能，例如手勢識別／繪圖／輔助功能和列印支持。
UIKit提供的UI組件可以大致分為以下4種類型：
欄（Bars）：包含了上下文信息來指引用戶他們所在的位置，以及控制項來幫助用戶導航或執行操作。內容視圖（Cintent Views）：包含了應用的具體內容以及某些操作行為，比如滾動、插入、刪除、排序等等。控制項（Controls）：用於執行操作或展示信息。臨時視圖（Temporary Views）：短暫出現給予用戶重要信息或提供更多的選擇和功能。iOS官方已經為開發者定義了一整套完整的UI類-子類（對應的是我們可見的操作控制項）及功能，比如button按鈕控制項，按鈕的點擊行為，禁用狀態等，都有了現成代碼可被研發人員拿來直接使用。
我們在設計方案之前，儘可能先了解到Ios預定義的控制項及其可實現的功能，儘可能的復用官網提供的控制項和功能，一方面是為了保護用戶使用iOS系統系統所獲取的行為——含義一致性，另一方面也提高了研發人員的生產效率。
但是面對著用戶需求，實在需要改變的時候，可以考慮自定義控制項，此時需要拿出具有說服性的證據來支撐你的自定義控制項。而證據便是調研歸納出來的用戶大類模型，這些用戶模型的行為特徵決定了產品該以何種形態為用戶服務。若單純為了研發效率，而犧牲掉用戶行為習慣所帶來的體驗或商業機會點，那就是產品經理在權衡取捨環節的失職了。
基於以上的分析，我們需要對時間控制項進行適當的修改，自定義時間控制項，滿足更大面積的用戶群體。
C類用戶的典型行為是在訂票行為上具有周期性，比如在經濟發達地區的長三角、珠三角、京津翼地區，城際往返，周末誇城市往返的行為比較普遍。針對這類用戶的訂票行為，可以在技術上進行跟蹤，並計算出周期，在用戶其他變量(出發地-目的地、乘車人)固定的前提下，對時間變量進行行為預判，推出複合用戶活動周期的日期默認提供到用戶。
最後，在可選範圍內，將輔助性行為進行隱藏式布局。根據場景，出發地默認定位當前所在城市，但是若數據不更新，可以快捷進行本地手動定位。對於選車次，選座位，選價格區間這些不重要，不高頻，但有需求的任務流程，提供可選入口，隱藏二級信息和流程，轉化成可選項，供熟練或專家用戶學習後使用。
至此，設計從理論向實踐落地全部結束。感謝大家的寶貴時間！
作者：青木，集創堂聯合創始人，公眾號：集創堂
本文由 @青木 原創發布於人人都是產品經理。未經許可，禁止轉載。