<menuitem id="mh6do"></menuitem>

    
    
    <em id="mh6do"><ol id="mh6do"><mark id="mh6do"></mark></ol></em>
    <ol id="mh6do"></ol>
      <em id="mh6do"><tr id="mh6do"></tr></em>
      <dl id="mh6do"><ins id="mh6do"><thead id="mh6do"></thead></ins></dl>

      <sup id="mh6do"><menu id="mh6do"><small id="mh6do"></small></menu></sup>

      動效的價值——B端產品動效運用分享

      原創文章 分類: 經驗/觀點 版權:
      7472 240 360 23
      2018-10-18
      75.2
      首頁推薦

      在無限的信息體量和有限的用戶瀏覽范圍之間求得平衡,讓用戶看到全部創作中他最想看到的那一面

      在B端產品的設計過程中,我深切體會到動效能在很多體驗領域起到四兩撥千斤的作用。于是我將自己這些年來做動效的思考,結合B端產品的一些固有特點,來和大家聊一聊動效設計在B端產品體驗設計中的意義。


      既然是談B端產品的體驗設計,那么就免不了要與C端產品做對比。在我看來,B端產品與C端產品在大的體驗趨勢上是趨同的,對于大多數用戶而言,都希望自己在工作與生活中是順利、愉悅的,而用戶體驗就是為了讓用戶順利、愉悅而生的。也就是說,不管是B端產品還是C端產品,其體驗的本質都是圍繞著使用的效率與愉悅感為核心展開的。那么這次我們就將目光聚焦在B端產品,來看看在這個領域都有哪些亟待解決的設計難點:


      Image title


      針對這四個特點,我沉淀出一套解決B端產品體驗問題的方法,它們分別是:信息折疊、路徑梳理、提升效率、概念物化。接下來,我將通過具體的案例,來詳細展現動效在B端產品體驗設計中的意義。



      涉及案例簡述:

      Dataphin:一款將阿里建設數據中臺的能力商業化的產品

      QuickBI:一款用于數據可視化分析的BI工具


      Image title




      切換式:不同信息共用同一區域。

      Image title

      案例1:

      問題分析:初次進入Dataphin,我們會提供一張業務流程圖來解釋Dataphin的工作流程。為了降低理解成本,我們對每個流程都添加了文字說明。然而由于流程本身已經很復雜,頁面中排版中加入說明性文字會使得流程的排版拉長,用戶很難通過一屏瀏覽完整的功能流程,體驗不佳。

      Image title


      解決方法:我們發現用戶一開始關注的業務的全流程展示,然后才會仔細查看每個業務的詳細說明。當用戶將注意力放在查看詳細說明的時候,是顧不上看全流程的。因此我們將“看流程”和“看說明”的場景區分開,共用同一塊區域,從而優化信息排布。

      Image title


      案例2:

      問題分析:在QuickBI中,同一套icon需要應對兩種不同的使用場景:當用戶沒有選中任何圖表的時候,點擊任意類型的圖表icon,即可新建一個圖表;當用戶選中某一創建好的圖表時,再點擊圖表icon,則是為該圖表切換類型。所以為了確保用戶的認知清晰,我們需要將兩套使用場景區分開。


      下圖中,我們嘗試了靜態的布局思維,雖然可以區分場景,但也造成了導航條過高,導致空間冗余,壓縮了創作空間。

      Image title


      (其實這個問題不止我們家有,用過Adobe公司的AE的同學應該清楚,AE里面的形狀工具體驗也很鬼畜,用戶不選擇任何圖層的時候,使用形狀工具可以新建形狀,當用戶選中某個圖層的時候,使用形狀工具是針對該圖層創建蒙版,兩種不同的功能卻沒有任何樣式或操作上的區分,對新手用戶來說是相當不友好的)


      解決方法:用戶創建圖表和切換類型是兩種不同的場景,不可能同時存在,在布局上沒有必要讓兩套icon同時存在于界面。因此使用切換式,利用鼠標對圖表的點擊、失焦可以靈活切換兩套使用場景。

      Image title




      交疊式:不同入口內容共用同一區域。

      Image title

      問題分析:圖1是用戶在Dataphin中所創建的一張邏輯表,我們需要保證用戶在屏幕內盡可能多的獲取信息,因此邏輯表中的空間利用就顯得很重要。在原有交互中,我們為用戶提供了搜索功能,同時我們也在思考有沒有更優的信息布局方案,可以為用戶展示更多的數據。


      解決方法:在圖2中,我們需要在頂部區域找尋與用戶搜索操作不重合的場景,并把它們重疊起來。這里我用到交疊式的思路,即將搜索框收起來,只在頂部保留搜索入口,這樣在布局上就可以讓搜索與標題交疊使用同一塊區域,優化了布局。

      Image title




      衣柜式:在原有入口上擴展出更多信息。


      Image title

      問題分析:在下圖中,側邊導航的信息過多,壓縮了創作區域,我們需要為導航“瘦瘦身”。

      Image title



      解決方法:通過用戶調研,我們發現導航的名稱對于新用戶來說很有必要,但隨著用戶對產品的逐漸熟練,名稱重要性漸漸下降。我們需要通過動效,找到合理的展示形式,來兼顧新老用戶的使用需求。

      Image title



      設計的價值:

      通過動效優化信息布局,既保證了單位面積內盡可能多的展示有效信息,又避免了信息過載帶來的干擾與閱讀疲勞,使得用戶每次只需要專注眼前的使用場景,提高了獲取數據的效率,這便是視覺設計師在項目中的價值。




      Image title



      層級路徑梳理:解釋類目之間的層級嵌套關系。

      Image title

      問題分析:在Dataphin中一共包含了80多個功能點,我們將這些功能點梳理歸納成5個大類目和20個子類目。因此我們既希望用戶能明確每個類目下包含的子類目,又希望用戶在選中子類目的同時,也能明確感知自己處在哪個大類目下。


      下圖中,用戶從首頁切換到數據資產版圖,我們想要讓用戶明確信息的嵌套層級,靜態的思維只能用雙Tab形式展現。雖然解釋了層級關系,但也使得導航高度過高,壓縮內容區域,加之案例中的資產版圖本身還包含三個子類目,于是,同一個頁面出現了三層Tab,相當惡心。

      Image title


      解決方法:將嵌套路徑通過動效的方式展現,運動軌跡可以暗示用戶子類目從哪里展開,其余類目被收到了哪里,用動效的方式解釋了層級嵌套路徑。明確了層級嵌套關系,節約了為解釋嵌套路徑而鋪展出的信息所浪費的頁面空間。

      Image title




      操作路徑梳理:解釋操作流程的遞進關系。

      Image title

      在Dataphin中,用戶在創建邏輯表之前,會經過一系列繁瑣的配置工作,如下圖中,用戶需要經過“定義維度”-“定義主鍵&來源邏輯”-“定義層級”三個步驟。由于操作流程復雜,我們為用戶設計了鉛筆線動效,讓用戶時刻明確自己操作所處的位置,也方便回退操作。

      Image title


      設計的價值:

      通過動效梳理路徑,使得B端產品復雜的產品邏輯更為清晰,降低用戶的理解是成本,縮短因查找路徑浪費的時間,提升工作效率。同時,將操作路徑巧妙的隱藏在運動路徑當中,可以節約為了展示路徑關系而浪費的頁面空間。



      Image title



      借位式:盡可能多的展示信息,縮短操作路徑。

      Image title



      問題分析:在QuickBI儀表板中,用戶需要導入已有的數據集以配置圖表內容。數據集由用戶自行創建,一般來說,B端產品用戶文件命名比較偏長,正常情況下下拉框很難直接把名稱顯示完全,用戶還需要將鼠標hover到名稱上才能查看完整的名稱,操作路徑被拉長了。


      解決方法:我們在側邊欄展開的一瞬間向兩側借一部分空間,使得名稱獲得了更多展示空間。盡可能多的展示信息,縮短操作路徑,提高效率。

      Image title




      響應式:每一步操作都有回應,引導式的體驗。

      Image title

      問題分析:再QuickBI儀表板中,用戶創建圖表的操作為:先拖動字段進入對應軸區,軸區便能讀取字段內的信息并生成數據可視化。這一所見即所得的操作對老用戶而言是高效的,但對于新用戶而言認知成本則有些高。


      設計思路:我們需要通過響應式的設計來引導用戶學會這樣一個操作。首先,用戶的鼠標滑過字段,字段會高亮響應,提示用戶此處可點擊,從而吸引用戶學會點擊拖動字段。接下來,我們通過軸區內的文字提示,告訴用戶字段可以被拖入該軸區。用戶將字段拖入軸區的時候,對應的軸區會高亮響應告訴用戶字段可以被拖入軸區,同時字段會根據拖入路徑是否正確給出響應,如果正確,字段會劃入軸區,如果錯誤,會給出錯誤提示,如果用戶執意操作,字段會彈回原處。這樣我便構建了一套完整的響應流程。通過層層響應的方式,減少用戶在每一步操作上的困惑時間,幫助用戶快速掌握這一操作手法,提升工作效率。

      Image title




      元素聯動:強化元素間的關聯關系

      Image title

      工具型產品中很多操作是相互關聯的,而且這樣的關聯關系通常是細微的,因此需要我們通過動效強化元素之間的關聯關系。案例中圖表的每一列指標可以自由配置,通過微動效,讓用戶一眼就能找到新增的指標,提升操作效率。(蘋果在新版的Mac系統中也有采用類似的設計,體驗很棒)

      Image title




      框架聯動:強化框架層面的關聯關系

      Image title

      聯動關系在框架層面也同樣適用,比如導航區域與創作區域之間就存在拉伸聯動。這樣的動效前提,建立一整套元素的適配規范,便于開發與團隊協作。這個過程會很繁瑣,也是B端產品看不見的巨大工作量。

      Image title


      設計的價值:

      每一個微小細節的打磨才能匯聚成高效的用戶體驗。提升效率的點小而且零散,總結起來即是用戶的操作是強反饋的,從而增加用戶嘗試的信心;用戶的操作是有引導性的,即增加用戶繼續探索的信心;用戶的操作路徑是盡可能被縮短的,以節約時間。滿足這三點的均可以看作是設計在提升效率方面的價值。




      Image title



      視效運用:運用視覺設計的能力,物化抽象的概念。

      Image title

      問題分析:QuickBI中有一個叫“創作區”的模塊,是用來介紹QuickBI產品能力的。我們需要在這個區域向用戶展示QuickBI所具備的能力與工作流程。由于QuickBI是面向行業分析師的BI工具,其所要傳達的概念對于新用戶來說比較生澀復雜,這就需要我們在產品流程展示設計上盡可能簡單易懂。


      下圖是1.0版本中的效果,其對流程的設計僅停留在圖形的堆砌,對業務的表述不夠清晰,也就很難向用戶傳遞我們的產品價值。

      Image title


      那我們來看看視覺設計是如何物化抽象的概念的。

      首先我梳理出QuickBI工作的四個步驟:獲取數據、創建數據集、數據分析、數據展示。

      Image title


      接下來我們思考一下,當我們需要對某人講述一個很復雜的概念的時候,我們通常會打個比方。那么我接下來要做的,就是為這套抽象的概念“打個比方”,因此我要為它們構建了一個有故事性的場景,那么這四個步驟應該是某種靜止且持續運轉的工廠,它們之間需要某些動態的介質將其串聯起來。

      Image title


      于是我進一步挖掘視覺樣式,構建出了場景原型圖。

      Image title


      進一步完善視覺效果,得到了最終的成品:零散的代碼被收集車間收集,產出數據表進入加工工廠,工廠將其加工成數據集,運輸進分析臺,分析臺通過“儀表板、電子表格、數據全屏”三種方式對數據進行可視化分析,最后將分析結果通過數據門戶和郵件訂閱的方式對外分享。

      Image title


      設計的價值:

      通過動效設計,將抽象的概念具像化,將復雜的流程簡單化,大大降低了新用戶的學習成本,使之可以快速上手產品體驗。



      最后,我將我的動效設計方法沉淀下來了一套以方盒為載體的方法論——方盒理論:“置身于三維空間下,信息的體量是無窮的,我們需要為其尋找合適的載體,在無限的信息體量和有限的用戶瀏覽范圍之間求得平衡。即讓用戶看到全部創作中他最想看到的那一面。”這即是我所構建的以六面方盒為基礎的信息載體,并為我的一切動效解決方案提供了理論支點。

      Image title


      B端產品并非大家印象中那樣的索然無味,其中有很多體驗是值得深挖的。動效僅僅是其中的一個層面。隨著近幾年B端領域功能點逐步完善,用戶對體驗提出了更高的要求,B端產品的體驗設計需求也會漸漸升溫,也希望有更多這個領域的優秀設計師能和我做朋友。

      Image title



























      三魚先生

      合作請加qq1303928878

      4782粉絲/34關注

      原創小生
      B端產品-QuickiBI體驗設計B端產品-Dataphin體驗設計

      掃描二維碼
      去手機端查看海報

      京ICP備14007358號-1 / 京公網安備11010802014104號 / Powered by 2008-2018 UI.CN

      印度快乐8开奖号码
        <menuitem id="mh6do"></menuitem>

        
        
        <em id="mh6do"><ol id="mh6do"><mark id="mh6do"></mark></ol></em>
        <ol id="mh6do"></ol>
          <em id="mh6do"><tr id="mh6do"></tr></em>
          <dl id="mh6do"><ins id="mh6do"><thead id="mh6do"></thead></ins></dl>

          <sup id="mh6do"><menu id="mh6do"><small id="mh6do"></small></menu></sup>
            <menuitem id="mh6do"></menuitem>

            
            
            <em id="mh6do"><ol id="mh6do"><mark id="mh6do"></mark></ol></em>
            <ol id="mh6do"></ol>
              <em id="mh6do"><tr id="mh6do"></tr></em>
              <dl id="mh6do"><ins id="mh6do"><thead id="mh6do"></thead></ins></dl>

              <sup id="mh6do"><menu id="mh6do"><small id="mh6do"></small></menu></sup>