## ##

        設(shè)計中的故事思維

        2017-09-20 09:48:29 閱讀 236628 本文來源:微交互
        分享至:

        大概所有的設(shè)計師都知道深澤直人,并且都贊賞過他設(shè)計的這個壁掛式CD機。

        20170920094607142.jpg

        深澤直人自己是這么介紹他的設(shè)計的:

        一天,我一邊聽著從敞開蓋子的 CD 播放器播放出來的音樂,一邊看著旋轉(zhuǎn)的 CD。旋轉(zhuǎn)的形象讓我想起廚房里由馬達(dá)所驅(qū)動的通風(fēng)扇,當(dāng)你拉下通風(fēng)扇的線繩,葉片就開始轉(zhuǎn)動;過一會兒,當(dāng)葉片的旋轉(zhuǎn)趨于穩(wěn)定,風(fēng)的聲音也隨之變得恒定了。我想,如果在 CD 播放器里內(nèi)置一個揚聲器,把它掛在墻上聽,感覺應(yīng)該會很好。......當(dāng)拉繩被拉下,CD 開始慢慢地旋轉(zhuǎn),音樂播放出來,就像氣流從風(fēng)扇中吹出來一樣。

        深澤直人沒有夸夸其談他的設(shè)計是如何的有創(chuàng)意,如何的漂亮。他講了一個故事,在這個故事里傳達(dá)了他的設(shè)計想法,產(chǎn)品操作方式、使用情境;而觀眾從第一句“一天”開始,就被他帶入了故事中,仿佛身臨設(shè)計師當(dāng)時所處的情境。

        回憶一下,似乎每個偉大的設(shè)計師都是說故事的高手。也許他們早已意識到,故事對人的影響無以倫比。 

        從遠(yuǎn)古時代開始,人類就通過講故事的方式來傳授經(jīng)驗,認(rèn)識未知世界。自然進(jìn)化讓人類大腦對于講故事這種信息接收處理模式變得越來越強、越來越敏銳,直到現(xiàn)在,人的大腦對于故事仍然“不可抗拒”。 

        講故事已被證明無數(shù)次它是溝通交流、說服他人的利器,作為設(shè)計師也許你已經(jīng)知道講故事的方式能更好地傳達(dá)設(shè)計理念。但更重要的是,故事思維對于用戶體驗設(shè)計的作用遠(yuǎn)遠(yuǎn)不止于此,除了幫助你的設(shè)計方案被買單,鼓勵溝通合作外,故事思維還可以應(yīng)用到設(shè)計的全流程中:探索理解目標(biāo)用戶及其所處的領(lǐng)域情境,激發(fā)創(chuàng)意,創(chuàng)建設(shè)計原型,評估設(shè)計。

        什么是故事思維

        在談?wù)撊绾螌⒐适滤季S運用到設(shè)計中之前,我們要先定義一下什么是故事思維。 《故事:驚人力量的背后科學(xué)》給故事下了一個定義:故事就是關(guān)于主人公戰(zhàn)勝困難,去實現(xiàn)目標(biāo)的描述。 

        這個框架定義,確實可以映射到一部諾蘭的好萊塢大片,或者一個故事會小文章中。但注意,這里我們想討論的不是故事框架本身,而是故事這種形式之所以無往不利的魔力是什么,能否把這種魔力特征抽象提煉出來加以應(yīng)用?對于此,我嘗試做了提煉分析,并把它叫做故事思維。

        在我看來,故事思維的核心啟示包含以下幾點: 

        以人為中心的描述視角

        每一個故事都有主人公,即使是丑小鴨的故事,也是擬人的視角去敘述。所有故事都要向觀眾交代:他是誰?他想要做什么?他的動機是什么?對于用戶體驗設(shè)計師來說,需要弄清楚的是目標(biāo)用戶是誰?他的目標(biāo)和動機是什么?

        基于情境的描述激發(fā)共情和想象

        我們沒有去過19世紀(jì)的倫敦,但可以想象福爾摩斯是在一個怎樣的城市里與犯罪斗爭;我們也沒有見過飛檐走壁,卻能夠想象武林高手凌波微步、踏水無恒的樣子。人的大腦能自動填補上故事的留白,而優(yōu)秀的作者更是能通過環(huán)境、心理等細(xì)節(jié)的描寫讓讀者仿佛身臨其境,喚起讀者最大程度的想象和與故事人物的共情。當(dāng)設(shè)計師身處陌生的業(yè)務(wù)領(lǐng)域時,所面臨的一大挑戰(zhàn)是如何讓團隊統(tǒng)一對問題和目標(biāo)的認(rèn)知,而集體的共情體驗是團隊達(dá)成認(rèn)知統(tǒng)一非常有效的途徑。

        沖突矛盾是貫穿整個敘述的核心線索

        在故事中,主人公必然面臨著沖突矛盾,這可能是內(nèi)在的矛盾也可能是外部矛盾。沖突是整個故事的戲劇張力所在。對于產(chǎn)品設(shè)計來說,用戶所面臨的困難和痛點是設(shè)計機遇所在——找到痛點,并解決它。

        每一個故事都有開頭、中間、結(jié)尾。

        每一段的體驗便如一個故事一般,有著開始、過程與結(jié)尾:開始起于用戶與產(chǎn)品/服務(wù)的接觸點,過程中的核心體驗、以及用戶離開時的終值體驗是否讓其滿意是用戶留存的關(guān)鍵因素。

        20170920094704880.jpg

        故事思維與設(shè)計思維的結(jié)合

        講故事非常有效,但它并不是一種單獨的新設(shè)計方法,我們應(yīng)該把故事思維融入現(xiàn)有的工作方法中。事實上,很多日常的設(shè)計工作都跟故事思維相關(guān),只是我們沒有主動意識到這一點。

        前文說過,故事思維可以應(yīng)用于設(shè)計全流程中。設(shè)計流程盡管不盡相同,但提煉抽象后,一個設(shè)計流程基本可以表述為“探索—定義—構(gòu)建原型—驗證”。

        20170920094721215.jpg

        探索

        當(dāng)設(shè)計師開始著手一個項目時,首先要做的是對相關(guān)領(lǐng)域進(jìn)行深入的調(diào)研,尤其是要了解目標(biāo)用戶。在這個過程中,設(shè)計師可能會收集二手研究資料,進(jìn)行相關(guān)利益人訪談、數(shù)據(jù)分析、問卷調(diào)研,用戶深度訪談等一系列的研究方法手段。如果不加整理,這些信息大部分是一些無結(jié)構(gòu)化的調(diào)研結(jié)果,用戶體驗設(shè)計師需要把這些研究信息還原成人的面貌:用戶是誰,他們背后的故事是怎樣的?

        在這個階段persona是一個好用的方法,通過整合歸類用戶信息,塑造出不同類型、特征、行為的用戶原型。要注意的是,為了避免persona是泛泛無用的描述,每個人物原型都要指出他的目標(biāo)、動機是什么。人物有了目標(biāo)和動機,才有了構(gòu)成故事的契機。

        有時在項目過程中可能沒有時間或資源去做完整的用戶研究,在這種情況下,我們?nèi)匀豢梢酝ㄟ^建立臨時人物角色,在團隊成員中建立起對目標(biāo)用戶一致的認(rèn)知。設(shè)計師可以召集團隊相關(guān)的成員,讓所有人都寫出自己對目標(biāo)用戶的理解和猜想,然后分別講述各自撰寫的用戶故事,故事不光可以解釋用戶的特征、動機和目標(biāo),還能描繪出行為過程的細(xì)節(jié)、用戶為達(dá)成目標(biāo)碰到的困難。接著經(jīng)過討論、分類、投票、聚合,整理出最終的臨時人物原型。在這個共創(chuàng)的過程中,團隊成員自然而然地建立了共情的體驗,有了一致認(rèn)知的基礎(chǔ)。盡管這個結(jié)果缺少真實用戶調(diào)研的驗證,但是隨著項目的進(jìn)行,我們可以回過頭來不斷調(diào)整改進(jìn)用戶角色模型——比起每個人各自拍腦袋的去想象用戶,這絕對更有效。下圖是中國大學(xué)MOOC考研項目的臨時人物角色,由產(chǎn)品、設(shè)計、開發(fā)、測試集體共創(chuàng)而成。

        20170920094739424.jpg

        定義

        當(dāng)設(shè)計師收集了充分的研究信息后,需要進(jìn)行信息的分析和思考,定義出設(shè)計到底要解決什么問題,解決一個真正的用戶痛點還是一個無傷大雅的小問題,這兩種設(shè)計方案的價值是天壤之別。可是要如何結(jié)構(gòu)化地思考推理得出有價值的設(shè)計目標(biāo)呢?我們?nèi)匀豢梢曰氐焦适碌臄⑹逻壿嬛腥?,在場景故事中發(fā)現(xiàn)沖突線索——這可能是最有價值的設(shè)計機遇。

        Allan Cooper在他的《交互設(shè)計精髓》一書中提到在研究結(jié)果和方案設(shè)計之間存在著一個鴻溝,他提出的方法是建立場景腳本,然后基于場景來設(shè)計。場景其實就是一種故事模板,但是Allan Cooper的場景比較寬泛,沒有給出一定的框架格式。我嘗試給出一種通用的敘述模板,在這個模板中會集合前期收集到的用戶信息,包括:用戶是誰,他的目標(biāo)和動機是什么,當(dāng)前的替代解決方案是什么,過程中的痛點是什么,他的情緒感知是怎樣的,他所期望的體驗是怎樣的。以下是我給出的場景敘述模板:

        作為【persona】,他希望能【達(dá)成某個目標(biāo)】,因為【動機】。他現(xiàn)在使用【當(dāng)前解決方案】,但是存在一些【問題和痛點】困擾著他,每當(dāng)【觸發(fā)動機場景和頻次】,他必須【當(dāng)前行為流程】,這時他會覺得【情緒體驗】,他想如果能【期待的體驗】就好了。

        【問題和痛點】是用戶所遇到的沖突矛盾,如果這個問題對于用戶來說很重要,他一定有了【替代的解決方案】,【情緒體驗】也反應(yīng)了用戶對于現(xiàn)在這個替代方案的不滿程度以及對潛在新方案的期待迫切程度。以上通過這樣的邏輯敘述,也許你能夠找到一個合理的答案:什么問題對于該用戶來說是最重要,什么設(shè)計目標(biāo)對于用戶來說是最有價值的。

        構(gòu)建方案

        有了明確的設(shè)計方向后,接下來設(shè)計師會去嘗試尋找盡可能多的解決方案,選出最令人滿意的創(chuàng)意進(jìn)行原型設(shè)計。原型的目的是為了最低成本地表現(xiàn)出解決方案是否解決了用戶的問題,是否比現(xiàn)在的競品更好地提升了用戶的生活/工作。線框圖是常用的原型工具,但是線框圖的成本仍然較大,而且容易陷入表現(xiàn)形式的細(xì)節(jié)中;有經(jīng)驗的設(shè)計師有時會使用流程圖,但是流程圖對于表達(dá)設(shè)計概念的缺點是不夠直觀易懂,并且同樣容易陷入一些局部分支交互流程中去。

        如果你想快速表達(dá)設(shè)計概念,這個階段故事版是一個好的設(shè)計工具。圖片加文字的形式是人類最易于接受的講故事方式之一,人們能很快領(lǐng)會到用戶是如何使用你的解決方案,或者你的方案解決了用戶的什么問題。使用故事版的一個技巧是,你可以用對比的形式畫出用戶在解決方案前后的流程和體驗,比如之前用戶必須到路邊等待、揮手打車,現(xiàn)在通過打車軟件可以坐在辦公室里直接叫車。

        你不必因為不擅長畫畫而對故事版感到望而卻步,大部分情況下你都可以通過拼接網(wǎng)絡(luò)素材的方式來快速制作故事版。中國大學(xué)MOOC在做首頁改版設(shè)計時,我用暴走漫畫做了一個簡單的故事版,盡管有些粗糙夸張,但還是能相對直觀地表現(xiàn)出新方案的預(yù)期效果。

        20170920094803305.jpg

        網(wǎng)絡(luò)上也有一些制作故事版的工具,比如通過storyboardthat (https://www.storyboardthat.com/),你可以很方便地使用他們提供的素材在線制作故事版。

        BTW:除了以上提到的設(shè)計方法,還有兩個我認(rèn)為與故事思維緊密結(jié)合的方法是敏捷開發(fā)用戶故事和用戶體驗地圖。用戶故事是敏捷開發(fā)用于描述需求和功能的一種方式,它有著固定的表達(dá)格式:作為一個<角色>, 我想要<活動>, 以便于<商業(yè)價值>,用戶故事保證了需求始終以用戶為中心,避免開發(fā)出用戶不需要的功能。而用戶體驗地圖是用戶體驗敘事的一種可視化表達(dá)方式,它包含了用戶與產(chǎn)品/服務(wù)接觸的全范圍空間、時間內(nèi)的體驗故事,幫助設(shè)計師既能縱覽整體體驗流程也能看到局部的交互故事。

        結(jié)語——帶著故事思維去學(xué)習(xí)和思考

        設(shè)計是一門跨學(xué)科的專業(yè),設(shè)計師總是擅于從其他專業(yè)中“竊取”知識和方法。比如從營銷學(xué)中學(xué)習(xí)提升用戶轉(zhuǎn)化的技巧(AIDA推銷模式),從心理學(xué)中學(xué)習(xí)信息組織的排版方式(格式塔心理學(xué))。在這個知識爆炸的時代,設(shè)計師每天都需要不斷地學(xué)習(xí)新知識來更好地符合工作需求。這種情況下,設(shè)計師所面對的一個挑戰(zhàn)是如何消化、融合不同學(xué)科領(lǐng)域的知識、方法,合理地運用到設(shè)計中去,并向團隊合作成員準(zhǔn)確傳達(dá)信息理念,讓自己的設(shè)計被買單。

        我的建議是你可以嘗試帶著故事思維去記憶知識、看待問題、思考方案,任何與人打交道的專業(yè)或多或少都會提到講故事這個概念:營銷人會講品牌故事;管理者會講商業(yè)故事;投資人會講資本回報的故事;這都是因為故事就是人類學(xué)習(xí)認(rèn)知的天賦技能。而設(shè)計師,首先要做到講好用戶的故事,然后進(jìn)一步重新審視故事思維,帶著它去學(xué)習(xí)、思考、實踐,也許你會豁然開朗。

        責(zé)任編輯:hlr
        分享至:

        聯(lián)系客服

        故障反饋