如何將復雜的設計需求簡單化?

新人設計師可能都會遇到這樣的問題:在設計一個復雜需求的時候,各種場景、可能性在腦中來回亂竄,常常覺得邏輯不夠嚴密。設計完成后,又被各路人質疑,提出各種異常場景,導致頻繁修改,縫縫補補。最終可能會出現(xiàn)兩種不好的結果:

1.只做了部分場景,很多異常場景沒考慮到,最終因為細節(jié)的不完整導致整個設計不可用;

2.什么功能都做了,用戶依然不滿意,表示找不到想要的功能;

本文就以「企業(yè)內(nèi)部權限分配平臺」的需求為案例,整理了之前處理復雜需求的一些思路。來講講在交互設計的過程中,如何避免以上兩種情況,讓我們的工作更好地服務用戶,體現(xiàn)價值。

 

 

?1. 理解需求?

首先,我想任何設計師在設計產(chǎn)品的時候第一步都是理解需求,這包括了需求的目標背景、角色場景、產(chǎn)品邏輯等,不同的需求側重點會不同,以「企業(yè)內(nèi)部權限分配平臺」的需求為例,目標背景和角色都比較簡單,但是一般涉及權限的產(chǎn)品,背后的邏輯就會很復雜,場景情況也很多。

和產(chǎn)品溝通,和用戶溝通,甚至網(wǎng)上找資料,都是理解需求的一些好方法。比如本次設計的需求是關于權限分配,這一篇《角色權限設計的100種解法》,就很好地幫助我理解權限分配背后的設計邏輯?。

包括理解需求內(nèi)的專有名詞,為其建立特殊的標識樣式,也是幫助自己、團隊、用戶更好地理解產(chǎn)品需求的一種方式。

名詞解釋

 

 

? 2. 需求結構化?

我們在最初思考需求的時候,肯定會從場景/問題出發(fā),想著怎么去解決這個問題,是以“人”的思維來思考這個問題的,這是必然的,也是正確的。但此時我們的思維是散點式的,例如當我們想到權限分配的需求時,可能會說:“這次我們要新增一個「崗位」的概念,讓權限和崗位綁定,不要和人綁定”,“對了,還有人員離職這個問題困擾業(yè)務很久了,我們這次要在人員離職的時候xxxxxx”。

所以,在最初的需求框架確定后,我得到的是這樣兩段文字:

看上去已經(jīng)非常全面了,但由于我們是散點式地收集需求,很多時候可能還是會遺漏,或者說錯誤關聯(lián)了內(nèi)在邏輯,導致一些邏輯沖突、漏洞。

此時,我們需要將我們的思維從「散點式收集」轉為「結構化梳理」。從需求說明里抽絲剝繭,我們可以得到:

? 用戶角色有三類:超級管理員、業(yè)務管理員、HR;

? 操作對象是:部門、崗位、人員、權限包;

? 可執(zhí)行的操作包括傳統(tǒng)的:增、刪、改、查,還有和本次業(yè)務相關的「關聯(lián)」,即權限的賦予;

各個對象之間的關系又是怎樣呢?我們把所有的對象兩兩組合,再把沒有關系的刪掉。

也就是:

? 在部門可以下設立崗位,崗位必須從屬部門

? 人員必須從屬某一部門

? 人員必須從屬某一崗位

? 權限包可以賦予給部門

? 權限包可以賦予給崗位

? 人員和權限包沒有任何直接關聯(lián),這也是本次權限分配的核心

這個具體的業(yè)務邏輯并不重要,不需要去費心理解,重要的是這樣一種結構化思考的方法,可以應用在后續(xù)各種各種的設計中。

對象間的關聯(lián),再和我們剛才梳理的人物、操作相結合,就可以還原成一系列的需求描述:[角色]可以在[A對象]下[操作][B對象],例如:超級管理員可以在部門下新增崗位;

至此,我們已經(jīng)可以建立【需求→功能對應表】

其中,紅色部分都是在之前散點式的需求羅列中沒有考慮到的功能點,通過結構化的梳理,我們可以提前把它們都一一補全。

這個過程可以減少我們最小顆粒功能點的遺漏,避免在做完大部分設計后,突然發(fā)現(xiàn)遺漏了xx功能,任務時間點又已經(jīng)到了,慌慌忙忙地加功能,就可能會影響整體的設計思路和框架。

 

 

? 3. 設計的減法:只考慮主流程?

完成了功能點的整理歸納后,就可以開始我們的界面設計啦!在最初的界面設計中,這三點需要做減法:

? 優(yōu)先進行框架設計,不要在一開始就考慮細節(jié);

? 優(yōu)先完成主流程,再考慮異常場景;

? 按照功能對應表將各個模塊獨立設計完成,再添加快捷操作;

當然,可以先把可能存在的異常、細節(jié)都記錄下來,以便后續(xù)補充。

比如,在人員權限分配的界面結構中,分為三個大模塊

在有了界面框架和功能對應表后,我們做設計會變得比較簡單,按照之前整理的【需求→功能對應表】,把每個小顆粒的功能細節(jié)填充到界面框架內(nèi)即可。

 

 

? 4. 設計的加法:回歸場景,考慮細節(jié)?

當主流程設計完畢之后,我們就要開始做加法了,在之前,我們一直是用一種純理性的視角來完成我們的設計,保持純理性的設計會有兩個問題:

1.很多業(yè)務場景靠邏輯思維是無法想象的,必須設身處地站在用戶去思考,才能理解場景,進而補充可能的體驗細節(jié)。

2.純理性的設計,可能在功能點上是完整的,但在用戶體驗上是缺失的。

例如,純從邏輯思維角度你能想到在一個企業(yè)里有人是沒有任何部門歸屬的嗎?然而現(xiàn)實中就存在這樣的情況:外包人員。不結合實際場景,我們也不知道用戶一天需要處理多少次重復操作,目前的設計對他是否足夠便捷。

作為一個企業(yè)內(nèi)部權限分配平臺,我們可以把部?、崗位、人員等對象作為初始線索,站在不同的用戶使用角度,沿著線索去全面地思考場景,修改功能。有一些實在難以理解的業(yè)務,找用戶聊聊也是一個好方法。

很快的,我們可以找到下面這些特殊場景:

a. 人員變動

? 新增人員流程:找到新加入部門→找到崗位→添加人,由于企業(yè)內(nèi)部還有一個最基礎的OA系統(tǒng),那么HR是否會需要重復操作,一個人員在不同平臺添加兩次?這是否增加了他的工作成本?

? 人員變動頻繁,是否容易遺忘?

處理方法:行政架構自動同步,紅點待辦。

我們與OA系統(tǒng)數(shù)據(jù)打通,自動形成四類待辦紅點:①人員新增;②人員離職;③行政部門新增;④行政部門刪除;

這樣HR就不需要重復做新人員的添加操作,只需要業(yè)務管理員把OA內(nèi)無法覆蓋的人員崗位設定好就可以,也不會出現(xiàn)遺漏的情況。

b. 高管兼職

例如某位高管:本身為A部門負責人,臨時兼任B部門負責人,那么當他不再負責B部門時,該如何處理他的崗位?離職?轉崗?似乎都不合適。

處理方法:新增崗位移除功能。

c. 外包人員

了解到現(xiàn)實情況中,外包人員是沒有部門歸屬的,但是實際上他們肯定也有自己負責的業(yè)務范圍和崗位,在初始化時如何安置沒有部門的人?

處理方法:新增一個部門,叫做“無崗位人員”,并且標紅作為待辦,提醒操作者去處理這些“無崗位人員”。

d. 人員離職/轉崗

在進行功能設計整合時,我考慮是否“人員離職”應該叫“人員刪除”更系統(tǒng)化?是否可以直接整合為一個“人員編輯”的功能,將離職、轉崗的操作合并?(實際上這2個功能操作起來確實比較相似)

處理方法:最終我依然保留了“人員離職”、“人員轉崗”的功能,因為這樣更場景化,用戶清晰地知道自己當前該操作什么。

目前對一個人進行離職操作的路徑是:找到原部門 →找到崗位 →找到人 →處理離職,而我們的企業(yè)有2500+員工,對于離職操作者HR來說,這個路徑是否現(xiàn)實?是否快捷?

處理方法:新增搜索功能,直接搜索人名→處理離職,這個功能也方便了其他找人的場景。

e. 等等...

諸如此類的考慮還有很多,例如新建部門的時候是否會有空部門,在企業(yè)進行組織架構重組時是否會有大批量的人員、組織變動,進而需要有批量操作,等等。找到最初的線索,站在用戶的角度沿著線索思考,進行全局掃描,就會發(fā)現(xiàn)很多需要做加法的地方,發(fā)現(xiàn)的方式可以是觀察、訪談、思考,任何方式。

在已經(jīng)保證了主流程的簡潔、清晰后,再用全局掃描的方式去搜集特殊場景,給我們的設計做加法,可以保證我們整體的設計框架是清晰可用的,而特殊場景是散落在骨干上的各種小分支。

如果我們可以做到,對所有的主干場景、分支場景了然于心,并且有自己的優(yōu)先級考慮,那么對于項目成員、用戶提出的質疑,我們也有足夠的理由來證明自己設計的合理性。

當然,場景基本考慮全面后,還有最后一步,就是統(tǒng)一交互,完善細節(jié),這一步也是設計上的加法。

 

 

? 5. 總結?

以上,就是一個針對復雜需求的加減設計法案例,總結來說有四個大步驟:

從實際場景出發(fā),發(fā)現(xiàn)問題,理解需求;

需求結構化:把本源的場景、需求結構化成功能對應表;

設計的減法:先解決最根本的問題;

設計的加法:回歸場景,全面考慮;

所以,交互設計師是需要理性和感性的結合,要有完全理性抽絲剝繭,提煉總結的能力,也要有貼近用戶關注情感的細膩。把自己的工作規(guī)范化,減少無效付出,也是我們的一種能力,希望本篇文章對新人設計師有一些幫助。

 

 

 

作者:傅文娟

公眾號: 網(wǎng)易UEDC

每天更新,
全站高品質素材免費下載!