訪談認識的開發團隊是怎麼運用 Wireframe 這個溝通工具,大概得到了這些情況:
以上幾位產品團隊中的角色看待 Wireframe 的方式都沒錯。除此之外《 UX 從新手開始:使用者體驗的100堂必修課》這本書的說法也很有趣,作者是這麼描述 Wireframe文件:
線框圖(Wireframe)就是建築設計中的藍圖,但簡潔的外觀讓某些人誤以為它們是輕輕鬆鬆就能完成的單純文件。
嚴格來說,真正製作完成的 Wireframe 是一種描述產品規格的技術文件,Wireframe 告訴團隊的設計師與工程師們如何執行計畫,讓專案的開發者們能夠確認規格流程、判斷難易度、評估所需時程等訊息。如果開發者們沒有辦法看著眼前的 Wireframe 開始動工,那就是溝通用的草圖,離製作完成的Wireframe 可能還差了幾步。
事實上,有許多團隊或企業在工作流程中不太重視使用 Wireframe 這個溝通工具,我見過的理由有:
先針對上述幾個情境討論。
有些人會覺得新專案比較適合導入新的產品開發工具,因為在比較龐大、歷史悠久的 Legacy 專案中,祈禱系統能正常運作已經阿彌陀佛了。
過去我在接手網站、APP的舊站改版案時,進行利害關係人訪談的過程也常聊到這個情境 — 深陷在 Legacy 專案中的人其實是抗拒改變的。他們多半吃足了苦頭摸索出一套勉強跟這個 Legacy 專案共存的方法論,改變可能會引起不知名的變(ㄅㄥ)化(ㄎㄨㄟˋ)。
此時可以回到 Wireframe 的上一步,從整理資訊架構著手,例如下圖,假設這是一個網站專案,就先列出所有找得到的網址規則,再填入此網址規則內前端頁面可以看見的重要功能。
此時要抓大放小,不用真的將每個細節都列出,盡量找出不同頁面的共同功能,大概做20~40%的頁面之後,就會發現許多 Legacy 專案為了解決某種情境,而將某幾個模組抽出來搭建了新的特殊規則頁面,但其實這些特殊頁面可能有80%可以還原成其他頁面共用的規則。(我見過有些 Legacy 專案看似複雜,但只是將一堆功能入口放在所有想得到的頁面,讓介面充斥著選單,但其實毫無用處。)
手上有了分析過的資訊架構圖,以及釐清了 Legacy 專案是怎麼「變通」的潛規則,相信會減輕對於 Legacy 專案的絕望感(?)。
toB產品很常踩入一個誤區,就是 UIUX 分不清,認為系統就是這麼複雜,做了 UX 只是「變好看」而已,專業的產品難用很正常。
事實上,UX 的改進重點之一是為了讓使用效率提昇,而不僅僅只是好看,規劃合理的產品,本來在視覺感受上就會「比較好看」,主因來自於認知負擔的減輕,看起來覺得很容易操作,不會害怕出錯的介面,能降低認知心理上的使用壓力。
舉個朋友協助某上市房仲企業A後台改版的栗子。
房仲企業A的大型看屋物件後台,本來建立一個物件上傳三十多張照片以及設定相關訊息欄位,要花工讀生半個小時的時間,全國的物件上萬筆需要維護,工讀生再多也不夠。
新的後台物件上架流程的改版案完成之後,新增物件的時間縮短到五至十分鐘內,大幅的提升工作效率,加快了全國物件維護的速度。
toB產品的用戶正因為在工作上大量使用系統,因此改善UX的效益直接與工作產出效益掛鉤,可以依此作為評估的標準。
這三個因素我都先歸納到「我們不需要UX」,但無妨。
雖然現在看起來很夯,但 UX 這個工作職位放到2010年可能也沒幾個人聽過,如何運用 Wireframe 來溝通的概念,十年前可能也只有跨國網路公司內才有專門的 UED 人員專職負責。
即使是 2017年的時空背景下,許多團隊恐怕也是邊找 UX 相關的資料,邊學習這些工作方式。
每一種工具有它解決問題的效益,產出 Wireframe 的過程,開發團隊獲得的效益有:
相關文章:
原文出處:淺談線框圖(Wireframe)