不僅在職場中要不斷刷“存在感”，以尋求獲得老闆的“信任感”，從而獲得內心的“安全感”，在任何一個團體中，“信任感”和“安全感”都是一種適合團隊發展的氛圍。因為他避免了團隊成員因為追求片刻的“安全感”而將主要精力和注意力放在盲目刷“存在感”、劃分地盤或者尋求“依附感”的行為上，降低工作效率。
言歸正傳，本片文章並不是什麼職場軟文，而是想到，作為一個設計師，你輸出的設計方案，是否也應該具有“安全感”呢？
答案的肯定的。方案的“安全感”所賦予的目標對象，主要產品和開發人員。
一、通用的“安全感”
1. 方案易讀性強
方案的易讀性，主要是指頁面整體信息的清晰度要高，除了基本的版本號、標題、設計者等頭部信息外，還要注意整體方案的排版佈局。
以移動端舉例，如果不是線上預覽方案的話，一般輸出的文檔內容是圖片格式或者pdf格式，這是需要考慮到圖片輸出質量的問題。一些軟件輸出的圖片質量品質不同，很影響閱讀體驗。所以有一個小技巧可以使用，那就是橫向上頁面不要過長。
人們在電腦上的閱讀習慣是從左向右，翻頁是從上至下，所以為了提升閱讀的便捷性，在全屏播放時，橫向空間上不超過一屏空間，可以在縱向上延伸，這樣用戶在瀏覽時僅需點擊或者滑動鼠標即可，會極大提升閱讀的便捷性。
2. 標註準確
每個設計師都有自己的標註習慣，但是無論使用引線標註，還是底部註釋等，精確性都是必須的；同時引線標註時，儘量避免引線之間出現交叉點。
3. 及時定義規則
在輸出方案的時候，很多細節是可以複用的，以及一些全局性質的交互操作，可以及時定義相關的統一交互規範。一來可以減少每次都要標註的重複操作，二來可以提升整體效率，及時查漏補缺。
交互規範可能不需要定義完整的從框架層、結構層到視覺層的所有規範，但是基本的控件規範制定的必要性還是很強的，包括彈窗樣式、加載樣式、手勢操作區域、文案使用等。
二、產品角度的“安全感”
有“安全感”的設計方案給到PM時，不僅能夠快速評審通過，同時還可以完善產品策略，推動項目落地。
1. 方案多樣性
給出不同版本方案，提供多種選擇思路，體現對需求的理解深度與專業性。因為產品可能只是給了一個參考或者框架，但是並不一定是適合自己產品本身的，這時候需要根據需求和預期結果來優化方案，這樣也是對需求深度理解的一個展現。
2. 流程細節完整
PRD更多涉及到頁面間的邏輯關係，頁面信息架構等問題，但是對於一些細節或者是邊界狀態，在方案形成初期，是很難預料到的。所以設計師在輸出方案時，要不斷去觸碰方案的“邊界”條件，找到極端情況、邊界狀態以及對應的反饋。
所以很多時候，PRD描述只是幾行文字，但是交互稿卻要給出幾十個頁面，就是這個道理。限於公司規範、項目緊急程度以及產品靠譜程度的影響，設計師無法奢求PRD裡面面俱到。所以，大部分情況下的邊界條件這些交互細節，需要設計師自己去主動補充完善，讓整個產品流程形成閉環。
3. 方案的後續擴展性
互聯網產品開發本身就是一個快速迭代過過程，所以對於某個功能模塊，很少會所有功能部分都完整後才上線，都是本著敏捷開發的原則，快速上線，快速迭代。
這種情況下，同一功能模塊每一版本的方案都是有聯繫的，往往是遞進的狀態。對於一些喜歡加功能的產品而言，會不斷的向頁面中增加功能入口。對於這種常規情況，設計師在設計方案時，需要考慮到方案後續的延展性，不能侷限在一個版本內。
儘管用戶體驗是優先的，但體驗不是一個短期或者幾天就能獲得收益的過程。設計過程不是直線，而是彎曲上升的折線，需要根據實際情況平衡方案與體驗。
例如：產品版本每週都上線一次，一週的時間，開發的工作量是一定的，能夠支持上線的功能必然有限，所以PM給出的功能方案很多時候是分拆來讓設計師支持的。
然後就會出現兩種情況：
- Case1：設計師接到本期需求後，開始絞盡腦汁給出當前最優的、體驗最好的方案——(努力說服）產品通過——開發上線。然後下一期接到新的迭代需求後，繼續絞盡腦汁給出新的方案，不過這次給的真的是“新”的方案，很可能推翻或者重構了前一版的方案。
- Case2：設計師接到本期需求後，優先向PM瞭解功能的迭代計劃——給出擴展性強（當前來看可能不是體驗最好）的方案——產品通過——開發上線。然後下一期接到新的迭代需求後，只是根據需求微調或者簡單增加功能入口即可，同時達到最優的體驗。
兩種情況顯而易見，可擴展性的設計方案需要時刻保持對需求的敏感性，因為可能PM不會及時與設計師溝通後續計劃，所以當面對並不完善或者簡陋的PRD時，設計師需要主動與PM溝通了解產品迭代計劃，增加方案的擴展性。
三、開發角度的“安全感”
1. 複用相關樣式
頁面邏輯清晰的方案，除了必要的信息需要特殊標註，對於一些不影響體驗和滿足需求的前提下，複用已有樣式是開發同學最喜歡的，這意味著工作量的降低。予人玫瑰，手有餘香，設計師在輸出方案時，對於以下相似的模塊或者功能，複用已有模塊，可以不必要再“炫技”似的給出一副華而不實的方案。
2. 邏輯清晰，標註準確
很多時候，開發可能會不看PRD內容，而是照著交互文檔開發，所以這個時候，除了清晰的邏輯以外，文檔上的標註要清晰、完整，避免一些“手快”的開發快速實現後，驗收時發現冒出來很多細節的bug。
3. 方案要分端
目前很多產品的Android端實現風格偏向於iOS，比如：浮層樣式等。但是一些成熟的產品，在不同端上的設計風格，還是會遵循平臺本身的規範的。
所以設計師在給出方案時，需要有所分端處理：
- 控件的樣式：彈窗、提示燈樣式平臺有各自的規範，在不影響需求的前提下，儘量使用平臺現成的樣式；
- 系統實現效果要有所瞭解，例如：iOS系統支持點擊狀態欄返回頂部操作，但是Android本身是不支持的，如果頁面增加當前操作，iOS端不需要開發，但是Android需要提新的需求排期。
四、結語
輸出一份具有“安全感”的方案，也是設計師必備的素質，為自己的方案負責，也為整個項目流程負責。
#專欄作家#
蝦米&胖喵，微信公眾號：pangmiaodesign，人人都是產品經理專欄作家。高級交互設計師（百度/愛奇藝），夫妻搭檔，貓奴。曾做過公益產品、影音媒體產品，目前專注於企業級產品、娛樂社區產品體驗設計。“有貓，就有一萬種美好！”
題圖來自 Pexels，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
