本文為我們介紹了中後台介面設計的基本流程，以及其中的注意事項。設計乙個產品的前提是要先了解這個產品想要解決的是使用者什麼痛點，核心功能是什麼，價值點在**等等。
先整體瀏覽下需求，對需求有個整體的認知，知道大概的框架、功能點是什麼。
這是乙個消化過程，從prd一堆文字，消化成，自己可以理解圖畫。
這一步當中要把邏輯理順，不懂的就問，千萬不要用猜的，猜一猜，無限可能啊。一不小心，就給自己挖坑了。
如果產品是涉及到流程的，那就要把整個流程畫出來。比如要設計審批系統的中後台。
前面兩步完成後，可以說對產品的理解已經沒有問題了。現在要把頁面串起來，所以我建議先畫草稿，不用很細緻，要大致規劃板塊。
關於原型的問題，如果是比較大的專案，建議還是先畫原型，因為前期原型互動上修改的次數會比較多，那麼設計師可以專注在整體頁面流程上的把控，而不把時間放在顏色、icon、插畫等視覺上的修飾。乙個大專案前期的討論、評審，修改個5-10次都挺正常的。
每次修改最好都更新下版本號，並在原型裡面加個【更新記錄】的頁面，記錄這次更新哪些內容。如果是大的更新，或者是功能的改變，最好寫上原因，方便後期可查。因為時間久了，往後翻真的會忘記。比起相信自己的記憶，還是爛筆頭吧。我也碰到幾次這樣的坑，某次開會去掉了某個功能，當時覺得不需要。後期又有人提這個需求，追溯到底是誰說不要的，結果怎麼也想不起來。所以要做到記錄可查。
如果產品前期有做競品分析，建議把競品分析的內容也寫在原型裡面。同時也把產品目標，使用者痛點這些都可以寫上去，這樣讓整個原型可以更加完整，也更有份量。後期如果遇到類似的產品要設計，就可以去回顧下之前做產品的記錄，考查的方向。
做原型時，可以對一些要點，進行補充，比如以下幾點：
比如新建產品完成後，是到產品列表，還是到產品詳情頁，因為前期沒有說明，開發就讓頁面跳轉到產品列表，但是事實上，是要跳到產品詳情。因為到詳情頁面，可以引導使用者進行下一步操作。如果到列表頁面，其實操作就被中斷了，除非產品的需求是，不斷建產品，但這種情況比較少。
要在原型旁邊補充說明並列出，所有狀態。如果狀態還會對應不同的操作，則需要把對應關係都列出來。同時介面中的列表，也需要把狀態和操作對應，不要隨意填寫，以致於開發看漏或者看錯了，要保持一致，減少錯誤發生。
按什麼順序排序，這也是個關鍵問題，按建立時間、更新時間，產品序號，優先順序等等，不同的需求會不一樣，所以不要去假設開發都知道。
前端校驗，還是後台校驗？基本上現在都是前端校驗，馬上給使用者反饋，而不是在使用者填完一堆的表單後，告訴使用者**出錯了。後台校驗屬於偏重的互動，容易給使用者產生心理負擔。
校驗問題，還會涉及到報錯文案。這個建議做個文件給開發，特別是剛合作的開發，也不了解對方的習慣，這樣減少後期更改文案的時間。也可以做個報錯規範，這樣後期的報錯就根據規範來就可以，不需要每次都來提醒。
之前有人提到這個提示文案是非必要的，因為前面已經有說明，當前輸入框是要填什麼內容。
原型評審沒有問題後，就可以進行視覺的設計了。
視覺稿上面，也同樣需要一些互動的說明，雖然前期原型上已經有標註。但是對於開發來說，他要看著設計稿，又開啟原型對著看，其實也是件挺討厭的事。而且有些互動，是需要介面的，比如下拉列表樣式、搜尋框(涉及模糊查詢)、進度條(失敗和完成)等等。
題圖來自unsplash，基於cc0協議
前端與後台的互動方式
在開發web應用時，前端與後端的互動方式分為以下幾種 1.href頁面跳轉模式 前端通過url訪問後端的servlet，後端返回乙個html頁面或字串 2.form表單提交模式 分為get和post 通過submit直接提交 非ajax 後端返回乙個html頁面或字串 3.ajax提交模式 分為ge...
利用angular與後台的互動
記錄的世界是強大的，不管天南海北還是五湖四海，如果利用angular js與後台的互動。angular js 在api上稱為是http服務 下面咱給乙個簡單的 看看 簡單的利用後台與前端的tab切換進行交換 埠有可能已經不能使用，但是記住這個方法，http服務 angular中的核心服務 http，...
Android的UI設計與後台執行緒互動
本文將討論android應用程式的執行緒模型以及如何使用執行緒來處理耗時較長的操作，而不是在主線程中執行，保證使用者介面 ui 的流暢執行。本文還將闡述一些使用者介面 ui 中與執行緒互動的api。ui使用者介面執行緒 1 public void onclick view v 210 start 1...