DMA01
淺談線框圖(Wireframe)

淺談線框圖(Wireframe)

Wireframe 在產品開發工作上扮演什麼樣的角色呢?

獸群之心 / Soking

嚴格來說,真正製作完成的 Wireframe 是一種描述產品規格的技術文件,Wireframe 告訴團隊的設計師與工程師們如何執行計畫,讓專案的開發者們能夠確認規格流程、判斷難易度、評估所需時程等訊息。

訪談認識的開發團隊是怎麼運用 Wireframe 這個溝通工具,大概得到了這些情況:

  1. PM:為了在早期確認專案規格,PM 跟客戶溝通使用,讓客戶對於主要頁面及流程能夠安心。
  2. 設計師:看著 Sitemap 或者流程圖始終沒感覺,至少有Wireframe的話比較能討論怎麼互動。
  3. 前端工程師:寫前端之前需要確認互動流程,有 PM 或設計師先繪製 Wireframe 用來溝通的話,比較容易理解,可以看圖討論各種狀況。
  4. 後端工程師:早一點看到 Wireframe 確認整體架構,可以跟大家一起想清楚前後台需要的資料庫欄位,提早畫押避免架構一直改。

以上幾位產品團隊中的角色看待 Wireframe 的方式都沒錯。除此之外《 UX 從新手開始:使用者體驗的100堂必修課》這本書的說法也很有趣,作者是這麼描述 Wireframe文件:

線框圖(Wireframe)就是建築設計中的藍圖,但簡潔的外觀讓某些人誤以為它們是輕輕鬆鬆就能完成的單純文件。

嚴格來說,真正製作完成的 Wireframe 是一種描述產品規格的技術文件,Wireframe 告訴團隊的設計師與工程師們如何執行計畫,讓專案的開發者們能夠確認規格流程、判斷難易度、評估所需時程等訊息。如果開發者們沒有辦法看著眼前的 Wireframe 開始動工,那就是溝通用的草圖,離製作完成的Wireframe 可能還差了幾步。

 

為什麼有些團隊不太重視 Wireframe?

事實上,有許多團隊或企業在工作流程中不太重視使用 Wireframe 這個溝通工具,我見過的理由有:

  1. 公司的專案是多年的老系統,沒有人知道完整的全貌
  2. 這個產品是toB,不需要UX
  3. 團隊沒有設計師,PM不會畫,也沒有時間畫
  4. 短期專案需要快速上線,沒有時間等 Wireframe,不能用模版就好嗎?
  5. 我們是敏捷專案,看到不對馬上動手,不需要 Wireframe

先針對上述幾個情境討論。

公司的專案是多年的老系統

有些人會覺得新專案比較適合導入新的產品開發工具,因為在比較龐大、歷史悠久的 Legacy 專案中,祈禱系統能正常運作已經阿彌陀佛了。

過去我在接手網站、APP的舊站改版案時,進行利害關係人訪談的過程也常聊到這個情境 — 深陷在 Legacy 專案中的人其實是抗拒改變的。他們多半吃足了苦頭摸索出一套勉強跟這個 Legacy 專案共存的方法論,改變可能會引起不知名的變(ㄅㄥ)化(ㄎㄨㄟˋ)。

此時可以回到 Wireframe 的上一步,從整理資訊架構著手,例如下圖,假設這是一個網站專案,就先列出所有找得到的網址規則,再填入此網址規則內前端頁面可以看見的重要功能。

接手架構龐大的 Legacy 專案,先從重新整理資訊架構著手

此時要抓大放小,不用真的將每個細節都列出,盡量找出不同頁面的共同功能,大概做20~40%的頁面之後,就會發現許多 Legacy 專案為了解決某種情境,而將某幾個模組抽出來搭建了新的特殊規則頁面,但其實這些特殊頁面可能有80%可以還原成其他頁面共用的規則。(我見過有些 Legacy 專案看似複雜,但只是將一堆功能入口放在所有想得到的頁面,讓介面充斥著選單,但其實毫無用處。)

手上有了分析過的資訊架構圖,以及釐清了 Legacy 專案是怎麼「變通」的潛規則,相信會減輕對於 Legacy 專案的絕望感(?)。

產品是toB不需要UX

toB產品很常踩入一個誤區,就是 UIUX 分不清,認為系統就是這麼複雜,做了 UX 只是「變好看」而已,專業的產品難用很正常。

事實上,UX 的改進重點之一是為了讓使用效率提昇,而不僅僅只是好看,規劃合理的產品,本來在視覺感受上就會「比較好看」,主因來自於認知負擔的減輕,看起來覺得很容易操作,不會害怕出錯的介面,能降低認知心理上的使用壓力。

舉個朋友協助某上市房仲企業A後台改版的栗子。

房仲企業A的大型看屋物件後台,本來建立一個物件上傳三十多張照片以及設定相關訊息欄位,要花工讀生半個小時的時間,全國的物件上萬筆需要維護,工讀生再多也不夠。

新的後台物件上架流程的改版案完成之後,新增物件的時間縮短到五至十分鐘內,大幅的提升工作效率,加快了全國物件維護的速度。

toB產品的用戶正因為在工作上大量使用系統,因此改善UX的效益直接與工作產出效益掛鉤,可以依此作為評估的標準。

團隊沒有設計師、沒時間等wireframe、用模版就好

這三個因素我都先歸納到「我們不需要UX」,但無妨。

雖然現在看起來很夯,但 UX 這個工作職位放到2010年可能也沒幾個人聽過,如何運用 Wireframe 來溝通的概念,十年前可能也只有跨國網路公司內才有專門的 UED 人員專職負責。

即使是 2017年的時空背景下,許多團隊恐怕也是邊找 UX 相關的資料,邊學習這些工作方式。

每一種工具有它解決問題的效益,產出 Wireframe 的過程,開發團隊獲得的效益有:

  • 容易理解的視覺化文件(比起密密麻麻的 Excel 規格表親切,容易理解流程)
  • 開發者不應該邊做邊找人逼問規格(這個按鈕按下去會發生什麼事?上一頁是哪一頁?)
  • 專案早期用 Wireframe 溝通比切版後才溝通好(反覆修改的成本是專案最致命的傷害)
  • 用 Wireframe 評估時程比觀落陰準確(開發者常被誤認為會算命,以為講幾句話就能估時程)
  • 越早消除模糊空間越好(很多開發者常聽到:你先做,我再補給你,然後又聽到:我昨天有這樣說嗎?)

 

相關文章:

 

 

原文出處:淺談線框圖(Wireframe)

 獸群之心 / Soking
獸群之心 / Soking

產品設計師以及 UX 教育講師。

Hahow線上課:https://hahow.in/cr/think-with-ux

工作聯絡:[email protected]

【產品規劃系列(三)】軟體 PM 撰寫規格書的三大工具之三,UI Flow
這篇文章說明了「Flow Chart」、「UI Flow」、「Wire Flow」的差異,透過漸進的文件產出,最終可以得到一份完整的功能/畫面規格。
Google UX Playbook — 【給新手的練習題】金融財經手機版
如果能依照本文的流程做完,基本上已經能熟悉專案中的需求與介面規劃階段。
[筆記] Facebook 資深產品經理聊聊產品與創新
今天下午在 Clubhouse 上聽了一場收穫良多的演講,講者和主持人 Ian,Albert,和 Han-Shen 都是在設計和產品管理上經驗豐富又願意分享的前輩,之前有機會在灣區和紐約向他們請益的時候就覺得收穫滿滿,這場 Clubhouse session 仍舊相當 insightful。此篇文章便是這場演講的筆記。