<strike id="g1ugu"></strike>
    <nobr id="g1ugu"><ruby id="g1ugu"><tr id="g1ugu"></tr></ruby></nobr>

  1. <font id="g1ugu"></font>
    <b id="g1ugu"></b>

  2. 
    

      <tt id="g1ugu"></tt>

        <rp id="g1ugu"></rp>
        首頁 - 網站建設 - 用戶故事地圖淺析(上)

        用戶故事地圖淺析(上) 返回列表

        笑笑2018-10-09編輯發布,已經有1748個小可愛看過這篇文章啦

        用戶故事地圖淺析

        引言

        本文圖文內容,來源于螞蟻金服體驗技術部“芝士會”分享。

        中后臺產品大多通過產品化工具來給用戶提效,隨著用戶的應用場景開始延伸到線上線下各個角落,設計師也開始思考如何從時間空間維度去關注完整的用戶體驗。因此用戶故事地圖作為一種常見工具,進入了大家的視野。但是體驗地圖到底能解決什么問題,該怎么用呢?很多同學也許并不太了解。這次分享主要是將我們在各類渠道了解到的關于用戶體驗地圖的各類說法做了一個總結,并結合了我們在工作中的實際運用,給有興趣了解該方法的同學提供一點我們的見解和看法。如有不贊成地方或更好的見解,希望可以不吝賜教,我們相互學習,共同進步。

        用戶發現你提供的產品真正的價值,就像這張封面背景圖一樣,往往要經過一段旅程,必定不是一馬平川。通過我們的專業知識、見解和洞察搞清楚用戶這段旅途當中坑在哪里、怎么填才能讓用戶走的更順。幫助用戶更容易獲取產品價值,幫助項目組獲得成功。

        A.怎么做?

        用戶故事地圖雖然是一個耳熟能詳的體驗工具,但事實上當你接觸的時候才知道并不容易。其中需要注意的要點很多,能找到的模型也很多樣,導致做一個正確的方向變得復雜,結果可能會產出一個適得其反的用戶故事地圖,或者什么都沒有產出,那我們到底該怎么做呢。


        我們在支持項目的過程中,初期會選擇采用“故事編寫工作坊”的形式來梳理產品的用戶故事地圖。一般是項目組成員共創的形式,參與人員包括:技術開發、產品經理、項目經理、設計師、用戶、產品老大。

        重要流程分成四個步驟:產品定義——梳理骨干故事——拆分故事——溝通確認。下面我簡要介紹下這四步分別需要做哪些事情。

        第一步:產品定義

        一般是在故事編寫工作坊準備階段,首先由PD提主導產出,主要有幾點內容:

        1.產品的目標用戶。

        2.解決了哪些問題。

        3.用戶目標。

        4.產品目標。

        將這些內容記錄在黑板上,與大家討論達成共識,最終確定產品定義。簡單來說,需要明確“我們為什么要做這個?”以及“用戶為什么要用這個?”明確業務訴求和用戶訴求為之后的設計提供了指導,不僅可以在接下來在討論的過程中不易迷失方向,還可以避免陷入設計細節糾結。基于業務訴求和用戶訴求其實就是為了不忘初心,是為了明確設計的初衷。所以,在做交互設計之前,一定要問自己這兩個問題:”這能給我們帶來什么價值?”“這能為用戶提供什么價值?”這一步可以讓項目組內所有人和用戶共同明確產品覆蓋的整個范圍。



        第二步:梳理骨干故事

        為了方便大家理解,我在這里舉一個大家生活都會發生的例子。故事的整個范圍:起點是起床——終點是到達公司。閉上眼睛,回想一下今天早上起床的過程。把這段故事分成這樣幾個階段,起床——洗漱——穿衣——出門——上班途中——到達公司。



        在真實做項目過程中,大家在這一步可能會寫出不同顆粒度的故事,需要設計師把控故事的大小,這段故事可以再往下梳理一層顆粒度更小一點的故事。比如起床就可以再拆分為:鬧鈴響了——掙扎——關鬧鐘——下床。剩下的故事卡片都可以繼續這樣拆分歸類。



        這樣我們骨干故事就有兩層,一級故事和二級故事,故事的發生從左至右是一個敘事流。



        這里需要注意的是,在真實業務中,故事的流程不可能是一帆風順的,情況會變得復雜,我們可以借助流程圖的圖例線連接我們的故事卡片。




        總結一下,我們在這步怎么做的。首先,我們在第一步確定產品整體范圍之內盡量的把故事講完整,比如我們這個例子,起床——洗漱——穿衣——出門——上班途中——到達公司。這樣我們項目組的所有人就可以對整個產品有個全局的印象。其次,我們需要注意是要講完整的故事,但是一定要廣度優先,而非深度,要做到一公里寬一厘米深。比如刷牙這個故事里面,找牙刷、擠牙膏這類故事在這個階段我們無須關注,不要過早的沉浸到細節中。在這步讓大家做到對產品只見森林不見樹木的狀態。



        第三步:拆分故事

        在這一步,我們需要在剛剛梳理的每一個二級故事下面做停留,去拆分二級故事獲取更多細節內容。如果二級故事是一個海平面的話,那二級故事以上就是海平面故事,那現在我們需要關注的是海平面以下更多不可見的故事。項目組會圍繞這個故事寫出很多細節來。我們可以按照以下幾個維度對細節進行歸類,分別是:故事細節、想法、痛點、機會、情緒。其中情緒可以通過固定的問題獲得,也可以通過用戶想法、用戶的痛點結合主觀判斷。



        在這個過程中,先讓大家在一定時間內按照自己的想法寫出來,每一條寫在一張卡片上,做到相互不干擾,然后每個人出聲說出自己的卡片內容,讓所有人了解并貼在墻上。

        項目組人在寫想法的時候,相當于腦暴的過程,這時可以通過一些問題來刺激大家腦暴出更多的內容,比如:

        1.用戶在這步具體做什么?

        2.用戶還有其他選擇么?

        3.用戶怎么做才能更爽?

        4.出現問題如何處理?

        5.其他用戶來到這里該如何處理?

        回到我們的例子,我們洗澡的時候有正常的流程,但當沒有熱水時這個流程就會發生變化。同樣,在真實業務當中,這類情況將更普遍的發生,所以這個步我們將盡量多的關注到所有場景的故事。

        做完這步,我們已經獲取到了足夠多的細節信息,整個項目組都會做到對產品又見森林又見樹木的狀態。



        第四步:溝通確認

        這里我們的故事已經變得很豐滿,甚至變得臃腫,所以溝通確認變得極為重要。我們在這步需要花費相對多的時間,大家對內容進行對標、充足討論,把公認的留下來,無用的踢出掉。同時可以區分要做的故事細節的優先級。



        依次類推,當所有故事梳理完成之后,就完成了如下這樣一張完整的用戶故事地圖了。



        總結一下,在這步,首先,我們需要對大家寫的所有卡片進行對標,排除無效故事。其次,因為我們一般項目時間不夠,開發資源緊張,不可能一口吃個胖子,所以把要做的事情達成共識排出優先級變得尤為重要。最后,并不是所有的故事卡片都需要在同一時間細化,在真實業務中有些模塊的故事是無法一開始就梳理清楚的,所以可以先寫個占位符,待合適的時機再做拆分。

        我們通過這種一目了然、格式一致的故事地圖,讓項目組所有人都獲得足夠的信息,讓項目有一個明朗的開發流程。


        • 用戶故事地圖
        • 用戶需求
        • 產品定義

        相關新聞

        來電咨詢 4146.com牛彩彩票
        <strike id="g1ugu"></strike>
          <nobr id="g1ugu"><ruby id="g1ugu"><tr id="g1ugu"></tr></ruby></nobr>

        1. <font id="g1ugu"></font>
          <b id="g1ugu"></b>

        2. 
          

            <tt id="g1ugu"></tt>

              <rp id="g1ugu"></rp>
              <strike id="g1ugu"></strike>
                <nobr id="g1ugu"><ruby id="g1ugu"><tr id="g1ugu"></tr></ruby></nobr>

              1. <font id="g1ugu"></font>
                <b id="g1ugu"></b>

              2. 
                

                  <tt id="g1ugu"></tt>

                    <rp id="g1ugu"></rp>