UI老司機才懂的那些事兒

大家好，我是MU.SIR。

在我自己一開始接觸UI設計的時候，會把UI設計單純地理解成平面設計的電子媒體化，直到后來逐步了接觸和學習到了交互設計和用戶體驗的知識，才慢慢明白這些才是UI設計中最與眾不同的地方。不僅如此，在實際工作中，我慢慢學習到了一些“不務正業”的知識，雖然看似和UI設計關系不大，但卻是在真實工作中慢慢了解到的，今天這篇文章，我就和大家分享從我的工作中收獲的一點不正經的UI工作方面的知識。

正常情況下，一款上線的內容型APP要能正常的使用，一般會有 客戶端（就是我們的APP）和服務器，不過有一些純工具類的app只要有客戶端就能正常使用，不需要服務器配合。

客戶端就是我們蘋果手機上或者安卓手機上用的app，客戶端一般有IOS端和Android端，現在市面上基本上除了蘋果手機是IOS端，其他的都是Android端，只不過Android因為是開源的，所以由各種各樣的深度定制版本，比如什么三星，華為，VIVO，小米其實手機系統都是Android系統。

因為二者的開發的編程語言是不同的，負責IOS端開發的就是我們的IOS開發工程師，而負責Android端的是我們Android開發工程師

服務器主要儲存的是兩類東西，app的內容資源（數據庫）和各種前后端的代碼。其實服務器就是一堆的電腦主機里的硬盤，只不過都分布在各個地方的數據中心。除了客戶端，基本上所有的和app運行相關的數據都保存在了服務器。我們平常APP的內容都一開始都是在服務器上，只是當你打開App時，app會向服務器發送一些請求，告訴服務器，我這里要一些新的內容，你趕緊給我發過來，服務器接到指令后就會向app發送相應的內容，然后該內容才會通過app下載下來，然后在app上顯示出來。

后端，也叫后臺，你可以簡單地理解成負責APP后勤的部門，他負責了客戶端和服務器端各種數據的傳遞和交流，比如說個性化推送這個功能，其實就是后臺代碼根據你的搜索記錄，然后按照代碼的算法，把他覺得你會有興趣的內容推送給了你。

后臺功能的實現主要是由后臺開發工程師負責。

內容管理系統 就是一套網站系統，專門用來對APP服務器上的內容進行增刪改查。比如我們在各種新聞網站可以每天都看到各種各樣的新聞，它背后就是有一個新聞內容發布管理系統，也就是個網站，各個新聞編輯可以登錄那個網站發布和管理各種各樣的新聞內容，只有發布的內容才有可能會被推送到你的APP上。而像一些社交類APP，它們的app本身就兼具了一定cms的功能，我們發布的信息和照片，都會上傳到相應的服務器，然后其他人的app再從服務器上把我們發布的信息獲取下來，這樣別人就能看到我們發的動態了。

內容管理系統的設計與開發主要是一整套完整的網站開發的流程，不僅需要產品經理整理網站的功能需求，也需要UI設計師負責頁面的交互邏輯和UI界面，而開發工作主要由前端開發工程師和后臺開發工程師配合，前端工程師主要實現UI設計師設計好的后臺管理網站的圖形界面，而后臺開發工程師則負責搭建內容倉庫以及倉庫與外界交互等等一系列的功能。

舉兩個例子

就拿簡單的一個下拉刷新的功能來說，首先我們在客戶端里下拉，下拉之后觸發了客戶端向服務器端發送了一個請求，客戶端對服務器中的后臺說，哥們你幫我看看你的內容庫里面有沒有新的我這里沒有的，有的話就發給我，后臺接到指令后，檢查了一遍自己的內容倉庫中，發現剛剛有人通過內容管理系統添加了一些新的內容，符合客戶端的要求，于是就很爽快地把新的內容發給了客戶端，客戶端接收到之后就展現在了app的頁面里面。

再比如搜索這個功能，我們在app中輸入我們想要搜索的內容，然后點擊搜索，客戶端會把這個文字發送到服務器中的后臺，讓后臺進行匹配處理，看看內容庫中有沒有相應的東西，如果有的話，后臺就會把相關內容發送到客戶端上。

字段這個概念也是我在正式參與APP設計和開發的工作當中才了解的。它在整個產品的開發過程中是一個很重要的概念。從產品整理需求開始到開發完成，每一個環節它都有著重要的作用。

我把它理解為，字段是所有app頁面當中由內容管理系統控制或者由后臺動態生成其顯示內容的元素。簡單地說，就是這個元素的具體內容是可被改變的，那這個元素就是一個字段。

在一般的內容型app的頁面中，展示的所有元素的內容，有些是會變的，有些是不會變，會變的一般來說一是通過后臺管理系統來控制內容的顯示，比如新聞標題，新聞摘要，新聞來源等等，二是通過后臺計算后產生的變化數據，比如說一篇文章的點贊數、評論數，閱讀數等等，而不變的一些元素一般就是在客戶端內寫死的，這些寫死元素的內容只有通過更新客戶端的版本才能進行修改。

APP頁面中有哪些字段是每個崗位都需要知道的，以為這設計到后續的一些列設計和開發工作。產品經理一開始就需要把產品頁面中所有字段整理出來，告知設計師。

設計師要清楚知道頁面中的字段，比如說文字字段，文字的內容是會改變的，在排版的時候要考慮字數最多和字數最少的情況，圖片字段，你要考慮圖片是會不斷變換的，圖片的風格和處理方式對于后期真正app上線運營的效果都會有很大的影響。

有一些字段是可以根據設計師自身設計的要求來定義的，比如同樣一個商品的標簽的字段，你可以用純文字的方式，也可以用圖標的形式，當設計稿確定之后，這些字段的具體要求都需要梳理出來，比如我這個字段是文字的形式還是圖片的形式，如果是文字最多字數是多少，能不能不顯示，超出這個字數如何顯示，如果是圖片，圖片的尺寸是多少……等等一系列的具體問題的解決方案，把這些整理好形成一個文檔交給產品經理以及客戶端工程師和前后端工程師。

客戶端工程師需要知道你的設計稿中哪些是字段，哪些是寫死的（不可通過內容管理系統更改的）。如果設計稿中某個元素是活動的字段，他們在編寫代碼的時候會在該元素的代碼中留下一個“接收器”，用來接收以后從CMS或者后臺中傳過來的數據，這樣才能通過cms或者后臺來動態控制元素中顯示的具體內容，再比如如果一個字段限制十個字，如果后端傳過來的數據超過了十個字，客戶端工程師也要知道這樣的情況該如何處理，是用省略號，還是讓文字折行或者直接不顯示多出的文字……

前端工程師，CMS的網站是前端工程師寫的，產品經理或者交互設計師會出cms的后臺原型，原型中會告知前端工程師所有的字段，包括輸入文字的字數限制，上傳圖片的尺寸限制，以及哪些是必填項哪些是選填項等等各種各樣的具體要求。

后臺工程師也要知道要有具體哪些字段，他們會跟客戶端工程師、前端工程師進行溝通，這樣他們才能知道把服務器的數據傳到客戶端中的哪個接收器中去，如果有需要，他們也能對一些數據進行預處理。

在我自己的工作中，經常會遇到各種頁面改版的問題，在原有基礎上進行調整，是最考驗設計師和程序員友誼的時候，如果你稍微不控制一下自己的腦洞，可能你覺得很簡單的一個改動就會讓程序員忙活大半天。對于開發來說，新寫容易調整難，調整代碼是一件很費時費力的事情，這有點像我們好不容易合成好一張海報，然后甲方跟我們說，我覺得這個光源的方向應該改一下，這下好了，所有場景里物體的光影都要重繪。所以，調整代碼并不是像外人想象的那么容易，很多代碼調整的過程中會出現很多新的問題，開發人員都需要去一一解決。

保證交互流程不變

在頁面改版的時候，除非是產品提出需要，不然盡量要在保持原有交互邏輯和功能的基礎上對頁面進行改版，如果一定要動交互，最好和開發人員進行一定的溝通，讓他們對改動的方向有一些了解，讓他們有一些心理準備，同時也可以把你的思路和開發人員進行探討，說不定一些有經驗的開發者會告訴你一些更好的解決方案。

保持視覺一致性，建立基本的設計系統

一致性不僅僅是為了視覺上的美觀和統一，在開發過程中，也可以大大減少程序員的工作量，如果你的頁面的組件都是統一或者有一定邏輯性，程序員在開發過程中就可以按照你的設計邏輯進行開發，建立各種統一或者有一定邏輯變化的模塊組件，后期代碼調整過程中就能做到像sketch中symbol的作用，只要簡單地改組件的參數，就能應用到大部分界面里了。