e-Ways 威誠資訊科技::桃園網頁設計

桃園網頁設計

RWD網頁設計

桃園客製化網站

桃園響應式網站設計

桃園APP開發

桃園RWD購物網站

桃園響應式購物網站

桃園承攬商管理系統

桃園網頁設計,RWD網頁設計,桃園客製化網站,桃園響應式網站設計,桃園APP開發,桃園RWD購物網站,桃園響應式購物網站,桃園承攬商管理系統

知識觀點Article

 知識觀點 / 網站設計 / 詳細

Not only a UI spec | 設計文件的內容架構

21 May 2021
UI設計,UX設計,網頁設計,設計文件,UI Flow,Visual Spec,Wording Spec

在產品開發的流程中,UX Designer 往往需要參與不同的階段,包括前期的需求釐清、中期的設計開發以及後期的驗證評估等等,不同階段所面對到的關係人(Stakeholders) 也都不太相同。
而隨著設計工具的雲端化,共編、共享的功能也愈來愈完整了,設計部門因此著重於提供單一而完整的設計文件(Single Source of Truth),而不再像過去一樣,比較偏向根據角色分工分別提供相應的獨立文件。

UI設計,UX設計,網頁設計,設計文件,UI Flow,Visual Spec,Wording Spec

過往不同角色會分別產出不同的文件,現在則主要提供單一整合的設計文件

因著設計文件的統一,以及分享的便利性提高,愈來愈多不同角色會進來閱讀設計文件,過去以呈現UI spec為主軸的Wireframe,逐漸轉變成為各個開發階段所使用的「溝通工具」。但是每個角色在閱讀文件時,可能都會帶著不同的需求和角度,怎麼讓各角色能夠在文件中找到自己需要的部分,成為 UX Designer 們在編排設計文件架構時所面臨的問題。
究竟要如何讓設計文件可以更加被易於理解呢?在經過幾次的嘗試和跌跌撞撞後,我想或許可以從以下三個方向和步驟,來思考這個問題:

#1 瞭解需求和目的

不同的角色、關係人往往會帶著不同的目的來閱讀設計師的設計文件,因此首先必需要釐清的問題是:誰會來閱讀?他們為什麼需要?以我碰到的情境而言,大致上可以分成五個主要的角色,而他們的目標分別如下:

  • Product Manager:想要確定一開始提出的 Feature Requests 和 Use cases 是否有在此次的設計中被考量。
  • Project Manager / Architect:需要理解技術架構怎麼和設計相配合,譬如說UI上面的資訊是對應到後端資料的哪個部分。
  • Co-editors (Visual designer / Writer):需要知道整體的UI 流程,以及各個元素、資訊想要表達的意義,才能調整相對應的視覺設計和文字內容。
  • RD/FED:UI 的細節規格,包括UI flow, behavior, style & wording…
  • Researcher / Data analyst:需要明白設計的目標是什麼、設計假設為何、有哪些資料需要被收集以及需要利用資料驗證什麼問題等等。

#2 釐清需要的內容

根據第一階段整理出的人物和需求,接下來可以進一步歸納出設計文件所需要包含的面向,過程中會發現,有些不同角色的需求,事實上可以透過相同的主題內容來涵括,譬如說 PM 和 Researcher / Data analyst 都需要理解此次設計要解決的問題為何,只是對於PM而言是一種釐清和確認,對資料分析者來說則是做為他們後續工作計畫的基準。因此綜合來說,延伸第一階段的需求,文件內容應可以分成下面四個主題:

  • 問題描述:此次設計要解決的問題、需要滿足的案例為何?
  • 目標功能/假設:根據問題,我們提出的功能為何?為什麼我們認為這個功能可以解決此需求和問題?
  • 流程架構:為了滿足此功能,產品需要發展怎麼樣的使用流程?跟後端系統間的運作架構有什麼關聯性?
  • UI Mockups:具體的介面畫面和互動流程,以及細節規格規範

#3 編排文件和架構

大致上確定內容和方向後,最後一步需要思考的便是文件的編排順序。如同前面所說,設計文件常常被做為一種溝通工具,因此在順序的安排上,搭配討論流程和產品發展階段會是一個比較明確的方向。
基於這個方向,第一大區塊需要呈現的便是問題描述、功能設定和設計假設等,這往往也是進行細節設計前,需要先和團隊確認的內容。

UI設計,UX設計,網頁設計,設計文件,UI Flow,Visual Spec,Wording Spec,問題描述,功能設定,設計假設
第一區塊示意圖(問題描述、功能設定、設計假設)
UI設計,UX設計,網頁設計,設計文件,UI Flow,Visual Spec,Wording Spec,架構流程
第二區塊示意圖(架構流程)

最後一個區塊就是最主要的Wireframe 和細節UI Mockups了,這部分的排列方式可以基於 User flow 去編排,主要是讓閱讀的人可以比較知道整體排序的邏輯,也比較容易找到相對應的內容,Co-editor 可以根據架構疊加上其他內容,而細節的Design spec 也可以直接在畫面旁附註說明。

UI設計,UX設計,網頁設計,設計文件,UI Flow,Visual Spec,Wording Spec,架構流程

除了這三個區塊外,為了方便記錄和溝通,我後來也常常把各種相關的會議記錄直接列在文件周圍,或是直接記錄在相對應的 Flow / 功能附近,主要是讓各個資訊都可以集中在這裡,不會散落在各種不同地方,避免日後如果找不到時真的會超頭痛的!
這就是我近期在寫設計文件時的小小心得,如果你也跟我一樣苦惱的話,或許可以嘗試看看這三個方向,來找到最適合自己工作流程的編排方式喔!

文章摘自:AAPD

 


相關文章

桃園網頁設計 RWD網頁設計 桃園客製化網站 桃園響應式網站設計 桃園APP開發 桃園RWD購物網站 桃園響應式購物網站 桃園承攬商管理系統

桃園網頁設計,RWD網頁設計,桃園客製化網站,桃園響應式網站設計,桃園APP開發,桃園RWD購物網站,桃園響應式購物網站,桃園承攬商管理系統