APP開發如何做(zuò)好後台的(de)設計

APP開發時(shí)大(dà)家一般都比較注重前端的(de)産品設計，不可(kě)否認前端的(de)重要性，畢竟前端是直接面向APP的(de)用(yòng)戶的(de)。但是一個(gè)産品要達到功能完善，方便操作，支撐運營，後台的(de)設計也(yě)就顯得(de)非常重要了(le)。

如何在APP開發中做(zuò)好後台的(de)設計呢(ne)？首先要清楚的(de)是，後台産品和(hé)前端産品存在很大(dà)的(de)差異性。後台産品更加注重的(de)是業務邏輯的(de)清晰和(hé)功能的(de)實現，而前端産品對(duì)視覺設計和(hé)交互設計有更高(gāo)的(de)要求。下(xià)面，介紹一下(xià)後台産品的(de)設計方法與思路。

 

一、業務邏輯梳理(lǐ)

需求調研與分(fēn)析完成後，就是自己對(duì)内容的(de)消化(huà)和(hé)吸收。首先要做(zuò)的(de)事情是自己先清晰地理(lǐ)解一個(gè)産品。隻有自己理(lǐ)解了(le)，才能更好地推進産品進行開發。

先梳理(lǐ)清楚線下(xià)的(de)業務流程。将線下(xià)的(de)業務流程梳理(lǐ)清楚以後，然後才是對(duì)産品的(de)思考。一般有幾種幫助自己更好地梳理(lǐ)業務流程的(de)工具，如狀态圖，流程圖，泳道圖等等。這(zhè)些圖表的(de)作用(yòng)和(hé)用(yòng)法是不一樣的(de)。

狀态圖的(de)作用(yòng)是讓人(rén)清楚業務的(de)實現需要經曆的(de)狀态序列，以及引起狀态轉移的(de)事件，和(hé)因狀态轉移而伴随的(de)動作。狀态圖的(de)驅動是基于狀态的(de)轉換。

流程圖，相信大(dà)多(duō)數人(rén)對(duì)此并不陌生。但是，我看見很多(duō)人(rén)繪制的(de)流程圖并不是十分(fēn)規範。不規範的(de)流程圖，自己理(lǐ)解起來(lái)可(kě)能沒有什(shén)麽問題，但是别人(rén)可(kě)能就會産生誤解。

泳道圖，又稱爲跨職能流程圖。也(yě)是我所說的(de)流程圖的(de)第二步。作爲流程圖的(de)進階，泳道圖加入了(le)泳道表示不同角色(或崗位、部門等)。讓人(rén)在了(le)解業務流程時(shí)，也(yě)清楚由誰執行該動作。

也(yě)許很多(duō)人(rén)，覺得(de)花這(zhè)麽多(duō)時(shí)間畫(huà)圖會浪費很多(duō)時(shí)間。我覺得(de)仁者見仁智者見智了(le)。對(duì)于我個(gè)人(rén)而言，每天搗弄這(zhè)些圖，會很快(kuài)加深我對(duì)産品的(de)理(lǐ)解。特别是在業務比較複雜(zá)，而且之前有完全沒有接觸過相關方面知識的(de)時(shí)候，僅靠大(dà)腦(nǎo)很難有清楚的(de)思維，但是圖形化(huà)後卻能很好地理(lǐ)解。在業務整理(lǐ)上多(duō)花點時(shí)間整理(lǐ)，我覺得(de)是很有必要的(de)。

 

二、産品梳理(lǐ)

梳理(lǐ)好線下(xià)的(de)業務邏輯以後，要将它抽離搬到線上。這(zhè)個(gè)過程，可(kě)能會删除掉某些線下(xià)的(de)環節。依據産出的(de)流程圖，基本上可(kě)以大(dà)緻确定産品的(de)功能點。先理(lǐ)出單獨的(de)功能，然後加入角色(功能 + 角色)，準備工作做(zuò)好以後，可(kě)以開始搭建産品的(de)架構圖了(le)。先搭頁面，再确定頁面内的(de)功能，最後細化(huà)頁面内的(de)信息。在原型出來(lái)以前，可(kě)以拿産品架構圖先和(hé)别人(rén)進行一下(xià)交流。産品架構圖相較于原型圖，與數據庫的(de)設計思想比較一緻。而原型視圖化(huà)後，對(duì)于數據庫設計卻反而變得(de)抽象了(le)。另外，産品架構圖修改較快(kuài)捷，返工成本相對(duì)較小。

産品梳理(lǐ)好以後，就要開始搭建原型了(le)。先确定通(tōng)用(yòng)模塊：頁頭、頁尾、一級導航、二級導航。将産品架構圖的(de)内容填充到頁面内，并加入文字說明(míng)操作。最後細節添加，細節内容可(kě)以在頁面旁邊的(de)進行注釋。但盡量要單獨出一份詳細的(de) PRD。

 

後台原型的(de)設計是産品設計的(de)重要環節，在APP開發中一定不能忽視了(le)。