App專案實戰之路(三):原型篇

Keegan小鋼發表於2019-03-04

原創文章,轉載請註明:轉載自Keegan小鋼

並標明原文連結:http://keeganlee.me/post/practice/20160814

微信訂閱號:keeganlee_me

寫於2016-08-14


App專案實戰之路(一):概述篇

App專案實戰之路(二):API篇

App專案實戰之路(三):原型篇

App專案實戰之路(四):UI篇


本來,我是沒打算寫原型篇的,但考慮到關注我的人中也有部分產品狗,更重要的是,我一直認為,不懂產品設計的程式猿不是優秀的產品經理。而且,應該也有不少程式猿想往產品經理的方向發展的。所以,最後決定獻醜了。

原型設計工具

做原型設計,首先,當然是要講講工具。做原型設計的工具有很多,功能最強大的應該就屬 Axure PR 了,不過上手不容易啊。對於想快速開發一個原型但又沒那麼多時間去學習設計工具的我來說,只能說,Axure不適合我。好在,上手容易的設計工具還是有的。

POP – Prototyping on Paper

POP 是一款App,操作非常簡單,先用手機拍下草圖原型,然後開始編輯原型裡的哪個區域(比如按鈕)連結到哪個頁面,新增跳轉連結,之後就變成可演示的互動原型了。

App專案實戰之路(三):原型篇

POP 並不提供設計原型的任何UI元件,只提供了能在圖片上設定任意點選區域並新增連結到其他頁面(其實就是另一張圖片)。對於從草圖開始設計原型的人來說,這款App真是再適合不過了。

當然,侷限性也很明顯。首先,原型圖只能通過其他方式完成。其次,互動非常有限,只能實現頁面間的跳轉,其他互動比如同一頁面內的互動就別想了。最後,它只適用於App原型。

墨刀

墨刀是一款線上的原型設計工具,上手也很簡單,網站也提供了新手教程。墨刀的功能比 POP 就強大多了,除了支援手機App原型設計,也支援平板和網頁。本專案的原型就是用墨刀設計的。

App專案實戰之路(三):原型篇

墨刀吸引我的第一個優點就是提供了很多方便的元件庫。有一些單獨的元件如文字、按鈕、圖片、圖示、輸入框、單選框、多選框、開關、標題欄、搜尋欄、標籤等等,一拖即用,很方便。尤其是圖示,墨刀提供了很多常用的圖示,非常方便。除了單獨的元件,墨刀還提供了母版和組合。預設母版有輪播圖和下拉選單,預設組合有彈出框、列表項、Action Sheet、日曆等,都是一拖即用的。不夠用的話還可以自定義新的母版和組合。

墨刀吸引我的第二個優點就是對元件的屬性設定也比較全。就拿按鈕來說吧,可以設定背景色、前景色、邊框、陰影、透明度、位置、寬高、旋轉角度、圓角半徑、圓形或正方形,還可以設定按鈕的文字屬性,包括文字的背景色、文字顏色、字型大小、字型樣式、陰影、對齊方式,最後,也可以設定按鈕的圖示,不過圖示只能保持在文字左邊,無法調整位置。有了這些屬性,就可以很方便地將元件設計為自己滿意的樣子了,元件也可以做得差不多接近最終的UI了,即是說可以做到高保真原型。

不過,這裡要提一下,我並不建議產品經理們做原型時做到高保真。除了個別情況,比如需要給高層管理或客戶演示用的原型;又或者是創業團隊裡缺乏有經驗的UI設計師,甚至還沒有UI設計師;又或者是像我一樣的個人開發者,什麼都要自己來的。一般情況下,只要完成低保真或中保真原型即可。

墨刀吸引我的第三個優點就是對互動的支援非常好。墨刀除了支援頁面間的互動,還支援頁面內的互動。而且,頁面內的互動不是通過複製頁面來實現,而是通過為同個頁面新增多個不同狀態,實現狀態的切換。例如,點選主頁右下角的加號按鈕,會在加號按鈕上方滑動出兩個子按鈕,並且加號按鈕自己會旋轉變成關閉的叉號;再點選,兩個子按鈕會滑動收回下方,叉號再旋轉變回加號。

不過,墨刀的免費版不支援匯出和多人協作,圖片儲存不能超過100M。不過好在支援分享。其他人根據分享的二維碼或分享連結就可以檢視到可執行的原型了。

Mockplus

Mockplus 也是一款不錯的快速原型設計工具,和墨刀一樣,也提供了很多元件庫和圖示庫,甚至比墨刀還多。上手也同樣簡單,也是一拖即用。

App專案實戰之路(三):原型篇

不過,Mockplus 對於一些常用的元件的封裝程度卻不如墨刀,例如標題欄不能直接設定標題、標籤欄不能直接設定圖片、也找不到設定圓形圖片的方法、文字按鈕也不能支援新增圖示等。

Mockplus 在互動方面也是不足,頁面內的互動設計只能複製頁面,沒墨刀方便。其實,Mockplus 也有狀態的概念,不過不是頁面狀態,而是元件狀態,但目前我只在按鈕元件有看到狀態的設定屬性,可以設定正常、選中、焦點三種狀態。

其他工具

除了 Axure PR 和上面介紹的三款,還有很多其他的設計工具,比如 Balsamiq Mockups,以前的同事用過,我很喜歡它的手繪風格。不過,Mockups就不是免費的了,但可以試用。當然,網上也有破解版。

也有人提出使用 Sketch 做原型設計。無可否認,Sketch 也是可以設計原型的,PS、AI 等工具也同樣可以。至於互動,用標註的方式就好了。但這些工具,確切地說,更適合用來做 UI 設計,而不是原型設計。做原型設計,要求的就是能夠快速看到效果,不只是介面效果,還有互動效果。用UI設計工具來做,一是很難達到快速的要求,二是互動效果等於沒有。

設計原型之前

在開始設計原型之前,我還有一些話需要嘮叨一下。

首先,要確定好原型的受眾,是給UI設計師看的,還是給開發人員看的,抑或是給老闆或客戶看的。不同受眾決定了原型設計需要做到什麼程度。一般來說,如果受眾是UI設計師或開發人員,那最多隻要中保真原型即可;如果受眾是老闆或客戶,那可能就需要提供更多視覺細節的高保真原型了。

其次,要梳理好功能需求。梳理功能需求時,要以核心功能為主,儘量做減法,而不是做加法。

就舉我的專案的栗子,我的App中有一個需要給程式猿設定技術標籤的需求。現在看看加法怎麼做。首先,技術標籤可以分為三大類:移動端、前端、後端。接著,移動端的技術標籤有Android、iOS、Windows、React Native,Android根據語言還可以再分出Java和Kotlin,iOS則可以再分出Objective-C和Swift。前端標籤可以有HTML、CSS、JavaScript、React、AngularJS、Vue等等。後端標籤則可以新增更多了,資料庫方面的MySQL、MongoDB、Redis等,語言方面的Java、PHP、Golang、Python、Node.js等,其他的像Nginx、Docker、Spark、Spring等等。如果要把所有技術標籤都包含進來,真的太多太多了。那麼,再看看減法怎麼做。標籤只要三個就夠了:移動端、前端、後端。為什麼呢?因為初期使用者量不會很多,產生的內容也不會太多,沒必要分那麼細那麼多標籤,三大類標籤就已經足夠滿足需求。

再舉多一個栗子,我們公司目前正準備做一款新的金融產品,時間比較緊,核心功能只有一個,那就是要能實現交易。產品經理給我們演示原型時,包含了一些核心功能之外的輔助性功能,比如資訊、統計使用者看漲看跌的概率、風險提醒、修改使用者頭像暱稱等,結果所有這些不影響直接交易的功能全部砍掉了。另外,有一些介面流程也進行了簡化。

對需求做減法,就是要思考如何簡單快速地滿足目標。將核心需求看做一條鏈子,那麼,要判斷某個功能點是不是必需的,只要思考下如果把這個功能點去掉,鏈子會不會斷就知道了。

設計原型

設計原型時需要謹記一點:我是在設計原型,不是設計UI。設計原型的過程,也是一個梳理產品思路的過程,也是一個迭代的過程,從整體到區域性逐漸細化的過程。整體上主要就是產品的資訊架構,如功能結構、導航結構,區域性上主要就是頁面佈局和互動,如內容編排、頁面切換、按鈕點選等。

我設計原型時,和設計原型之前的需求分析一樣,也喜歡做減法。儘量減少頁面層級、頁面數量、頁面互動,儘量使得資訊扁平化。例如,使用者登入和註冊,我在一個頁面搞定。

直接以本人的專案為例,簡單講講我是怎麼進行原型設計的。

首先,對功能需求進行分類。根據我前一篇文章確定的功能需求,我整理出了以下的資訊結構:

  • 登入註冊
    • 手機號註冊
    • 手機號登入
    • Github登入
  • 釋出內容
    • 釋出問題
    • 釋出分享
  • 展示內容
    • 關注之猿的內容
    • 同棧之猿的內容
      • 移動端
      • 前端
      • 後端
  • 使用者中心
    • 個人資訊
    • 我釋出的內容
    • 我關注的內容
    • 我關注的人
    • 關注我的人
    • 我的訊息

接著,確定有哪些頁面。登入註冊需要為一頁,首頁以展示內容為主,同時需要新增發布內容和使用者中心的兩個入口。關注之猿和幾個同棧之猿,可以設為幾個Tab。使用者中心的每一個子項都可以各成一頁。釋出問題和釋出分享也可以各為一頁。

然後,將內容進行佈局排版。排版時,也不需要想太多,只要把同一層級的內容用最簡單的方式放一起就好了。記住,不要去想怎樣佈局才好看,那是UI設計時才需要考慮的。最後,我設計的首頁如下圖:

App專案實戰之路(三):原型篇

最後,就是對各個子頁面的設計了,也使用和首頁相同的設計流程。頁面太多,就不再貼出來了。

在整個原型設計的過程中,還需要不斷對一些細節進行調整和補充。如果你的原型設計完之後需要整理成需求文件提交給開發人員看的,那麼,設計頁面時,建議同時也可以思考下一些資料邊界和互動細節的問題,並批註在頁面旁邊,這樣,後續整理需求文件時就會方便很多。可能有些人習慣在整理需求文件時才來思考這些問題,但這樣的話很容易有遺漏,甚至可能根本不記得這個事。所以,設計時先思考,後面整理文件時再檢查有沒有遺漏,這樣,設計出來的產品就會嚴謹很多。

下圖就是我的登入頁面以及旁邊的批註:

App專案實戰之路(三):原型篇

寫在最後

最快的原型設計工具其實還是紙和筆,沒有之一。而設計原型其實也沒什麼特別的技巧,關鍵是要懂得使用者體驗,以使用者為中心去開展設計工作。推薦每個人都要看看《使用者體驗要素》這本書。


掃描以下二維碼即可關注訂閱號。

App專案實戰之路(三):原型篇

相關文章