三、功能架構(Function Architecture)
功能架構的目的就是搭建產(chǎn)品的骨架,有幾個(gè)主要的tab頁(yè),每個(gè)頁(yè)面有幾個(gè)區塊,對應多少種可能的操作。這樣去梳理一下,才知道各個(gè)頁(yè)面的功能和內容。
手機產(chǎn)品設計在流程上跟互聯(lián)網(wǎng)產(chǎn)品設計出入不大,在交付物上也有交叉點(diǎn)。很多新入行的朋友一直困惑于手機產(chǎn)品設計該怎么進(jìn)行,該交付什么樣的產(chǎn)出物給團隊其他人員。小公司產(chǎn)品經(jīng)理可能一條龍式的包攬了需求分析、競品分析、功能設計、交互設計等,交給技術(shù)人員的直接就是PRD(產(chǎn)品需求文檔)。大公司由于職能細分,可能會(huì )有項目經(jīng)理、產(chǎn)品經(jīng)理、產(chǎn)品設計師、產(chǎn)品架構師、產(chǎn)品策劃、交互設計師、視覺(jué)設計師等細分職位,那么設計溝通就成為更不可少的步驟了,時(shí)間都被浪費在流程和會(huì )議中了,大家經(jīng)常會(huì )糾結于功能或者設計的細節,忘了我們的核心用戶(hù),忘了產(chǎn)品的核心價(jià)值,無(wú)數次的pk,最終力求找到每個(gè)人認為的最符合用戶(hù)需求的設計方案。
本文旨在討論圍繞UED(用戶(hù)體驗設計)該在產(chǎn)品設計的不同階段提供什么樣的產(chǎn)出物,便于理清自己的思路,也便于團隊之間的溝通。具體交付物的實(shí)現方法,后續會(huì )有更詳盡的介紹。
概念模型是靈活性很強的文檔,你可以用它來(lái)展示某個(gè)特定產(chǎn)品中所蘊含的多種概念。它可以幫助你梳理一些模糊的想法并把它們記錄下來(lái),他們形成產(chǎn)品設計的基礎。由于是用于記錄和用戶(hù)體驗相關(guān)的潛在結構,所以受眾可以是項目組全體成員。概念圖可以任意的發(fā)散,供你組織零碎的想法。雖然概念模型僅僅說(shuō)明了一套概念設想,但是一個(gè)產(chǎn)品最重要的環(huán)節也就是概念的提出和成型,所以他還是很重要的。
***這是當初個(gè)人YY的一個(gè)掌上百度的概念圖,不代表實(shí)際產(chǎn)品立場(chǎng)***
人物角色,是指針對網(wǎng)站目標群體真實(shí)特征的勾勒,是真實(shí)用戶(hù)的綜合原型。我們對產(chǎn)品使用者的目標、行為、觀(guān)點(diǎn)等進(jìn)行研究,將這些要素抽象綜合成為一組對典型產(chǎn)品使用者的描述,以輔助產(chǎn)品的決策和設計。
功能架構的目的就是搭建產(chǎn)品的骨架,有幾個(gè)主要的tab頁(yè),每個(gè)頁(yè)面有幾個(gè)區塊,對應多少種可能的操作。這樣去梳理一下,才知道各個(gè)頁(yè)面的功能和內容。
五、流程圖(Flowcharts)

這個(gè)就不多說(shuō)了,呵呵~
交互原型和視覺(jué)稿都最好配合著(zhù)規范文檔交付。交互原型的規范文檔要梳理很多的全局交互問(wèn)題,比如焦點(diǎn)問(wèn)題、文案問(wèn)題、觸屏操作、按鍵操作等等。
手機產(chǎn)品設計跟手機平臺設計還是有很大的不同的。平臺設計要求規格嚴格,不能用太多隨性的設計,產(chǎn)品設計區分大小,有些小的產(chǎn)品可以很隨性很寫(xiě)意,大的產(chǎn)品功能架構比較復雜,但也不必一定等到各種構想和設計都成熟了之后再去做,而是應該允許試錯,快速上線(xiàn),收集反饋,反復迭代,不斷完善。
今天介紹的這8種交付物,不一定都需要交給團隊成員,有些也是為了自己梳理思路,所以還是要根據項目規模、時(shí)間安排來(lái)判斷,該產(chǎn)出什么樣的交付物最合適。
聯(lián)系客服