Vital BizForm

Vital BizForm is a B2B-oriented cloud form SaaS. Its main purpose is to digitize a large number of paper forms used by enterprises in the cloud, including design, filling, sign-off, query, statistics, printing and retention, etc. The goal is to help enterprises achieve paperless processes.

Keywords : UIUX, research, interaction, animation, wireframe,user flow, persona, competitive analysis, style guide

首圖2.png

ROLE

Product designer 、Product owner

PLATFORM

Web 、Mobile (RWD)

 

PARTNERS

Front-end engineer、Back-end engineer、Product manager

TOOLS

Sketch、Invision、Illustrator、After Effects


BACKGROUND

  1. 原系統銷量始終無法提升,透過相關資料與客戶回饋推測為產品定位問題,故希望透過改版改變產品定位以符合市場需求。

  2. 原始介面在使用性上有許多操作的問題,有些情況會讓使用者難以發現功能或是不會使用。

GOAL

  1. 主要客群從小型公司( 0 ~ 20 人)移至中型公司( 20 ~ 200 人)

  2. 解決目前使用者遇到的使用性問題,提升整體使用體驗

  3. 整合進新加入的功能,融入到原本的功能之中

  4. 將介面風格調整至公司新設計的產品視覺風格

RESULT

  1. 營收成長 650%

  2. 成功推行至公司人數 100 人以上企業


1.Reseach

 

1.1 使用者需求回饋、訪查

再重新設計之前,我們搜集了目前版本的使用回饋以發現現有問題, 我們取得回饋的方式大致上分為兩種:使用者訪談與客服提供的既有客戶回饋,我們將兩者搜集到的資訊加以整理並條列出來。

客服團隊與訪談得到的痛點

使用親和圖法將痛點歸納

🔍 Insight

我們歸納出五大最重要並且需要改變的地方:搜尋簽核權限表單製作以及通知,這些痛點也會依照重要程度、製作難易度去排進之後的設計計劃之中

 

1.2 原介面評估

這裡我們用到兩個方法來測試原本介面的易用性,頁面拆解與啟發式評估

1.頁面拆解

著眼於現有的產品畫面,我們將現有產品拆解成數個區塊,逐步分析每個區塊含有的項目與功能,試圖完全理解這個區塊背後的設計意圖與它是如何在產品中運作的

👉 了解產品的每個細節

👉 確保在之後的設計中不會有遺漏。

2.啟發式評估

拆解後的下一步就是對每個區塊嘗試定義現在遇到的問題並試圖去解決,定義的問題如:操作易用性、識別性、擺放位置、擺放層級、流程,將這些問題一一記錄下來並將想到的解決方法也註記在旁邊,清楚定義問題後逐個擊破

👉 透過介面上的重新佈局與安排層級來取得更好的結果

🔍 Insight

  • 進階搜尋介面過於深入導致難以發現
  • 左側階級有些是進入不同頁面,有些則是搜尋條件,再點選上會導致混亂
  • 填寫表單時常會忽略有分類以及上傳檔案功能,因為被藏在其他Tab之中
  • 右側的即時動態非必要時其實不容易使用到
 

1.3 競品分析

市場上有許多表單系統,我們從其中挑選出幾間性質與我們產品相近的作為分析的主要目標,我們主要的篩選條件為:能設計客製化表單、自由安排簽核流程。

🔍 Insight

資訊安排

  • 各家表單列表重點資訊包含:起單者(含有大頭照能更方便識別)、表單類型、重點表單內容、起單時間

👁 所見即所得

  • 設計表單採用所見即所得模式更能幫助使用者正確設計表單,而擁有預覽模式也更能讓使用者心安

📃 公司外部使用者

  • 有些表單情境不只是公司內部人員需要,公司外部人員(如訪客、客戶等)也需要填寫企業表單

📱 即時性

  • 表單填寫與表單簽核有很多情境需要在手機或平板上進行,故能夠支援手機將有更廣的應用範圍

2.Ideation

 

2.1 發想功能 Workshop

為了讓團隊能換位思考與熟悉更多產品的情境,我們辦了一場簡易型的 workshop 讓團隊從不同的角色出發去提供產品的建議,這次使用HMW的方法去做假設,如 : 如果我是哪個角色,我會希望這個產品擁有哪些功能,最後收斂大家的資訊後並討論得到共識,並將產出做紀錄。

🔍 Insight

大部分的角色皆需要一個簡易的資料呈現頁來知道今天有哪些事項需要完成

可能的解法大致上可收斂為:增加 儀表版頁 或增加 個人專區頁

 

2.2 模擬使用者情境

經由觀察,我們將使用者分為三種類型,分別為一般成員主管級管理員,為了能在思考流程時更能有效的思考每個環結,我們在思考時會加入簡易情境以讓三種使用者操作時都能確保順暢無虞。

一般成員 (Member):最常使用的功能為填寫表單、觀看表單簽核進度、列印或留存,使用頻率高,此類人數最多

主管級 (Supervisor):最常使用的功能為簽核表單、填寫表單、觀看表單簽核進度、交辦、討論,使用頻率高,人數次高

管理員 (Admin):通常為 HR 人員或是資訊人員,最常使用的功能為管理類功能如:設計表單、簽核流程設定、權限設定、統計數據、帳號管理...等,導入系統初期使用頻率極高,人數最少。

 

3.Design Development

 

3.1 資訊架構調整

整體評估過後,發現原始的資訊架構在面對兩種角色情境時,會造成有些功能不太清楚放哪裡或是有些功能放哪裡都不對的情況,於是我們打算先梳理一遍資訊架構後,重新安排位置,進而讓設定更方便

3.2 Wireframe

Wireframe 階段討論了好幾個版本,其中依據需求我們產出了兩個不同流程的 Wireframe。

Wireframe1

採用前後台分離式操作,由個別的Tab分別進入編輯表單樣板模式與新增表單模式

Wireframe2

採用前後台半合併模式,必須先點入表單類型後才能再選編輯表單樣板或是新增表單

🔍 Insight

經由團隊內討論,得出結論為 Wireframe2 雖然可能有助於提升操作的準確性,但是與現有的操作習慣與程式架構差異較大,所以最終的流程會比較偏向以 Wireframe1 的流程為主,Wireframe2 的流程為輔去做思考

 

3.3 Hi-fi Prototype and Testing

在做Mockup階段時由於團隊內討論有兩種想法,於是我們希望藉由測試了兩個不同樣態的介面來比較兩者的差異,我們製作了兩個高保真的 Prototype 去驗證哪個是比較可行的方案,也間接驗證到目前為止的操作行為是否符合使用者的期待。

PrototypeA

PrototypeB

我們這裡採用給予使用者一連串任務指示的方式去進行驗證,使用者需在 Prototype 上達成指示任務,而任務總共有三項,測驗的使用者總共有四人,測驗中會計算使用者達成每個任務的總時間,我也會在操作的過程中觀察紀錄使用者的操作方式是否有符合我們的想像,使用者分別於 PrototypeA 與 PrototypeB 完成三個任務後,我們會進行一個小型的測試後訪談,主要詢問體驗後的心得與有沒有遇到什麼認知上的問題。

測試、訪談結果統計

🔍 Insight

  • 後台管理者編輯表單與前台使用者新增表單可以嘗試使用統一畫面與按鈕
  • 新增表單按鈕放置在左側優於放置在左上角落
  • 分類的形式皆能看懂,兩種分類樣式無明顯差異

 4.Delivery

首頁

首頁呈現資訊為最常接觸到的資訊,如:公佈欄、待處理表單、已審核表單、個人簽報單與草稿

列表頁

列表頁為查詢表單或搜尋表單後呈現的畫面,重點擺在能否一眼辨識出正在尋找的表單與在篩選表單上是否順暢。

新增表單

新增表單因使用需求而拆成兩種模式,分別為文字清單模式與圖片模式

填寫表單

填寫表單時除了表單的內容之外,還有需多資料格式可以選填,如:分類、標籤、上傳檔案、簽核流程等。

查看表單

查看表單頁的左側區域特別設計了一個快速切換表單的區域,讓使用者在如簽核多張表單或是想快速查找時能更快速

企業設定 - 帳戶

將所有企業相關與站台相關資訊的呈現、設定都統一放到此頁

表單設計與設定

表單設計用 Tab 的方式分為四個大區塊 : 表單設計、審核流程、權限設定、其他設定

團隊管理

團隊管理分為兩大任務:1. 新增團隊成員 2. 修改組織與權限

Style Guideline

5. Product Management

這個專案走到後期已經不僅僅是產品的改版,由於產品需要頻繁迭代,我們團隊決定採用敏捷框架 Scrum 做為我們的開發流程,而我在產品的開發中除了擔任設計師之外同時也身兼產品負責人( Product Owner ) 這個角色,在這個框架流程中我學到了很多管理產品流程進度上的事物,包含制定產品Roadmap排定每個項目的開發優先順序制定流程與規劃共同討論方式,在歷經大小的迭代中,我們的流程也隨之成長變得更健全。

公司團隊使用monday.com服務作為專案管理的軟體,我們團隊將所有開發上的資訊在上面統一管理,確實做到開放與透明化

 6. Reflection

Alone we can do little; together we can do so much
— Helen Keller

在維護與設計這個產品的期間,我強烈體認到合作的重要性,不管是與工程的溝通或是跨部門的溝通,彼此的意見能相互影響、碰撞才能產出更好的結果,而透過這次機會也了解到如何用比較大的視角去看待一個產品的設計、規劃方向,雖然中途做了一些決定回過去看不一定是最好的,但是藉由一次次的修改與重新審視,還是能使產品一直不斷進步。