<address id="ttjl9"></address>

      <noframes id="ttjl9"><address id="ttjl9"><nobr id="ttjl9"></nobr></address>
      <form id="ttjl9"></form>
        <em id="ttjl9"><span id="ttjl9"></span></em>
        <address id="ttjl9"></address>

          <noframes id="ttjl9"><form id="ttjl9"></form>

          首頁

          量化設計價值(二)體驗度量深度實踐

          ui設計分享達人

          前言


          體驗目標的達成,需要合理且客觀的度量方法,體驗度量的實踐,需要度量框架的有力支撐。提高競爭優勢,提升客戶態度,保障產品可以即時的響應客戶的需求。本篇文章的實踐方法全部來源于酷家樂B端產品業務中的實踐案例,重點在于度量框架的深度實踐,如果我們的經驗能夠幫助到您,歡迎交流討論。 


          一、體驗度量怎么做?


          “體驗”是用戶純主觀的感受,從這個情況來看是很難被度量的。“體驗”同時也是一個比較抽象的概念,如果把一個抽象的概念拆解成一個可執行的策略,拆解的過程如何保證策略的有效性,是我們一直在思考的。面對酷家樂工具型、SaaS型、平臺型并存的產品體系,且存在錯綜復雜的用戶需求和業務訴求。在這樣的前提下對方法的確立需要更加的冷靜。 

          如何確定方法?我們需要的是一個完整的度量框架,以及能夠聚焦用戶體驗層為驅動,分解并有力的去解決問題。經過大量的實踐和驗證得到,抓住一個擊破點作為產品體驗提升的目標,并一種合理的方式進行推導和驗證,這是一種最直接度量體驗的標準流程性方式,這里的目標必須是:


          • 體現用戶主觀感受或者具有行為驅動的目標。

          • 基于業務目標定義+用戶訴求了解后,得到的以用戶為中心驅動的用戶行為。



          二、度量模型怎么選?


          面對設計圈內已經存在的和部分大廠創造的度量模型,評估優劣后最終我們選取了HEART模型。因為HEART是個比較全面和具備更多擴展性的分析框架,同時足夠的權威和標準,而且市面上的模型基本都被HEART的五維囊括。除了這些考慮因素外,再給出以下幾個明顯的優勢點:


          • 1、HEART同時涵蓋了定性和定量的不同數據維度。

          • 2、HEART框架同時包含了:宏觀和微觀的層面

          • 3、HEART模型并不單純的再定義體驗質量,同時也鏈接了商業價值。把用戶體驗的原則和收益驅動的指標關聯在了一起。


          undefined


          三、HEART模型簡介


          1.什么是HEART模型?


          多個大廠利用HEART模型拆解框架得到了深度結合業務的度量框架。是個比較全面和具備更多擴展性的分析框架。HEART是GOOGLE公司在實踐中提出,基于產出更好產品為目的,用來衡量產品整體體驗的度量評估模型。 

          它包含五個維度Happiness(愉悅度)、Engagement(參與度)、Adoption(接受度)、Retention(留存度)、Task success(任務完成度)組成,是Google用戶體驗研究團隊在實踐中為了準確的度量用戶體驗而總結提煉出的一個框架。 


          2.HEART模型的特性與應用場景


          目前市面上還存在PTECH、TEENS等體驗度量模型,而HEART模型的特性在于它”以用戶為中心“進行度量,同時度量維度全面,既包含宏觀的愉悅度,也有微觀的任務完成率,同時關注產品上的留存率,與業務目標保持緊密。在評估方式上,既有定性評估的愉悅度,也有定量評估的參與度、留存率等,可對用戶使用產品情況做一個完整的評估。 

          undefined



          四、HEART模型的詳細拆解指南


          undefined


          第一步:確定體驗目標

          體驗目標是體驗度量的開始,準確的目標決定了度量的質量。要提煉出準確而有效的體驗目標并不容易,通常會引入產品功能等業務因素,使體驗目標不夠單純,拆解出來的指標所反映的數據也很難歸因到體驗。故復雜項目可提煉多個體驗目標相互補齊,但每個都必須準確而具體。 

          那么如何確定體驗目標呢?

          體驗無法脫離于具體的產品服務存在,用戶的整體體驗感知積累于每一個接觸觸點,大多觸點常規而平庸影響不大,必須識別出達成業務的關鍵觸點進行深入分析,已提煉出體驗目標。 

          整體的思路是:首先分析業務目標,并就業務目標所落地的產品服務的鏈路進行拆解,分析鏈路后,找到其中對體驗有決定性影響的因素,提取其因素后,即形成體驗目標。


          undefined
          1.確定業務目標
          業務目標是整個產品服務的最終目的,體驗作為產品服務的重要評估維度,需要與之對齊。業務目標與所選取項目范圍有關,從整個產品到特定功能模塊,或者某個行為鏈路都可作為參與項目。根據選取的項目來確定業務目標,如“保持產品新舊改版的平穩過渡,降低改版造成的斷約率”、“提升用戶自主解決問題的能力,降低運營服務的壓力”等。注意業務目標與產品目標的差異,后者是對前者的產品化闡釋,可以具體到某項產品服務目標上。產品目標和體驗目標可以共同服務于業務目標,實現價值的達成。 

          ?示例:
          業務目標:在設計工具中商品素材的查找效率,輔助家裝設計師快速構建方案,提升其簽單率 
          產品目標:優化現有商品素材的查找邏輯,降低家裝設計師查找商品素材的成本 

          2.拆解產品鏈路
          產品目標需借助于功能鏈路來達成,將該目標達成過程的邏輯呈現出來,并分析其跳轉路徑、操作觸點,就是鏈路拆解過程。整個鏈路過程是用戶價值的直接承載,任何一個觸點的失效都將影響到整條鏈路順暢和效率。就鏈路整體而言,觸點越多、鏈路越長,操作成本越大;就某個具體觸點而言,其效率、易用性、易理解度也將影響整體的價值傳達。 

          為完整的拆解出整個產品鏈路,需要從“用戶側”、“系統側”進行分析,用戶側代表用戶視角下的功能使用流程,是主要考慮的維度,體現了以用戶為中心的設計思路;系統側代表系統在用戶交互過程中的需要執行的行為,是系統邏輯的直接體現。兩者的交互作用,將完整表達“信息”的流轉過程,最終作用到產出物上。 

          ?示例:商品素材搜索鏈路




          3.分析觸點并提取決定性因素

          選取對整個鏈路有重要影響的觸點進行設計維度上的分析,以找出決定觸點目標達成的決定性因素,這個決定性因素就是我們體驗上需要著重優化的點。在尋找“決定性因素”的過程中,避免將系統性能、業務功能、業務信息因素篩選出來,需要聚焦在設計維度上,諸如交互行為、界面布局、信息呈現、系統反饋等。 

          ?示例: 
          “確認輸入行為”、“搜索結果分類”、“不同分類的區塊劃分”、“結果數量”等。 

          對已拆分出來的各種設計因素來說,哪些算是決定性因素呢?一個很簡單的判斷方式是:反向判斷,即假設缺失這個設計因素,或不完整是否會對該觸點有“阻塞性”影響。 

          如有嚴重阻塞影響,則證明該設計因素很大程度上決定了觸點的目的達成,屬于決定性因素;若設計因素有中等的、輕微的影響,則可能不是本次優化的重點,不作為決定性因素。如“搜索結果的分類”影響用戶對搜索結果的信息獲取,是決定性因素?!按_認輸入行為”是常規設計行為,不算決定性因素。 
          當然,具體問題具體分析,在不同的功能場景下,同一種行為的影響程度可能不同。 

          需要注意的是,決定性因素的選取必須在具體的觸點中才有意義,脫離后無法判斷是否有阻塞性影響。另外,某些設計因素是否是決定性可能在跨觸點中體現出來,需要聯系整個鏈路進行交叉分析確定。




          4.體驗目標的提取與表述

          找到決定性因素及其為什么決定性的原因后,需要為其設定一個設計目標,來指示應向什么方面優化這個決定性因素。決定性因素只是現有功能的一種解法,可能存在其他更優解法或優化方向,我們需要基于決定性因素概括出“設計目標”,以新的設計目標來指引我們的優化設計。 

          ?示例: 

          決定性因素“搜索結果的分類”,引申出的設計目標為“更清晰的信息層級”、“更完整的信息”。



          通過鏈路觸點的分析,決定性因素的提取,設計目標的匹配,我們已對設計優化方向有了準確的了解。這個時候需要從設計師視角做一個完善而精準的”體驗目標“的表述。


          一個體驗目標需要與具體設計場景關聯后,才能產生具體而明確的價值,即設計目標落地到場景中后產生價值,表述思路是:在某個具體的鏈路觸點中,我們期望怎么達成這件事。可通過格式進行填寫: 
          使/什么用戶/用什么  做什么事/設計目標/完成什么事 

          ?示例: 
          家裝設計師  使用搜索功能  搜索素材時  對結果展示清晰的信息層級  來快速找到需要的商品 


          第二步:確定度量維度

          引入HEART模型的重要原因,正在于它的度量維度。由于它的度量維度多方位的表述了產品的使用情況,度量緯度不是一種標準,是一種分析框架和角度,決定了體驗目標應該被如何度量,進而影響信號的確定和指標的拆解,因此度量維度的選取至關重要。 

          HEART提供了豐富的五個維度,根據其定義,提供了你幾個可以衡量的視角。在實踐過程中,因每個體驗目標所對應的觸點的場景、交互、產品目的不同,我們只需要找到符合定義的維度即可。反過來看,一個與體驗目標不相關、不匹配的度量維度不能很好地度量體驗。 

          需要注意的是,HEART模型因其維度的廣泛定義,不僅僅可用于體驗目標的度量,也可以對產品目標、業務結果進行度量,對體驗目標的度量因要從產品因素中剝離出體驗問題,相對來說較為復雜,是本次敘述的重點。



          第三步:確定信號

          首先信號可以被定義為是一種信息的載體,其承載的信息往往反映的是用戶對體驗目標的成功或是失敗的結果,對信號的準確獲取將直接影響到對下游指標的確立。 

          信號的確定需以上游度量維度為標準范圍并引用體驗目標為重要判斷依據,避免過度發散,保證精準規范的同時,去結合當前有無體驗變量基準值作為條件,并使用成功或者失敗的結果來評估體驗目標的達成情況,最終提煉出信號。 


          以度量維度為標準并引用體驗目標確定信號

          通過逐一對度量維度進行體驗變量提取,有基礎值則進行對比的方式,無基礎值則使用趨勢的表述方式,結合業務目標的情況下,去概念性假設體驗目標的正向或反向結果,最終通過標準的格式提煉出信號,信號的提煉的可以用固定的格式進行書寫: 格式:用戶   用什么   做什么   體驗變量   趨勢&數值


          尋找體驗變量
          基于HEART模型的整個分析框架,拆解出最高頻和貼合體驗目標的常見體驗變量庫。在此框架的指導下,可以快速尋找需要的體驗變量。 

          ?示例: 
          (體驗變量:易操作度;有基準值) 家裝設計師 使用搜索功能 搜索素材時 易操作度 達到4.2
          (體驗變量:易操作度;無基準值) 家裝設計師 使用搜索功能 搜索素材時 易操作度 上升

          確定信號的注意事項
          ①信號的成功或失敗要能在行為或態度上準確的體現出來,失敗信號可能比成功更容易定義; 
          ②信號要易于被追蹤; 
          ③信號的敏感度要高,易于被檢測; 
          ④信號應與目標有高的相關度,同時避免被其他因素影響; 
          ⑤一個目標可能對應多個信號; 

          第四步:確定指標

          指標是衡量目標的參數,用于準確的描述目標。但通常很難直接從目標中確定出指標,需要借助于對信號的分析。信號是信息的載體,其中包含著變量信息,提取其中變量信息,即可獲得一個初始指標。 
          初始指標反映了客觀的原生數據,需要對原生數據做處理后,可得到一個能精準描述體驗目標的指標。 



          對數據進行處理

          體驗變量所直接產生的屬于原生數據,而一組數據通過某種分析加工后,可以成為一個更有價值的信息,如均值、中位值。選擇對數據進行哪種方式處理,受目標的影響較大,每一種數據處理方式,都有指向特征,通過與目標的匹配,可以選取出合適的數據處理方式。




          確定指標的注意事項

          ①指標應與目標和信號密切相關,指標越明確越清晰越好; 
          ②標應方便被持續追蹤,對信號的描述更敏感,方便做A/B測試。 

          ?示例: 


          案例A

          度量維度:愉悅度

          信號:家裝設計師    使用搜索功能    搜索素材時    易操作性達到4.0

          體驗變量:易操作度

          數據:易操作度評分

          指標:易操作度評分的均值



          五、總結


          看似復雜的體驗度量監控指標的拆解,可以概括為“體驗的問題定位”——“體驗的目標度量”——“體驗的客觀追蹤”。 

          1.“問題定位”是監控目標的根據,必須來源于具體的業務鏈路才有被分析和量化的可能,它是體驗問題在業務鏈路中被抽取出來的關鍵,并轉化為可度量的指標來進行監控,最終為后續數據洞察和可視化提供準確的數據來源,否則流于主觀,監控體系建立在不可靠的體驗目標之上,當然也就不可能有助于解決體驗問題。 

          2.而“目標度量”所運用的HEART模型作為度量維度,相當于一種體驗的定義標準,闡釋了什么是它所定義的用戶體驗。HEART模型以其全面的度量維度,能很好地實踐這一點。必須注意的是,對HEART模型下的五個度量維度的細化闡釋可能受不同產品特性、產品階段影響而不同,最終轉化出不同的客觀指標。 

          3.“客觀追蹤”是對在度量標準下的客觀變化的捕捉,捕捉其變量特征,建立常態指標,成為可靠的可監控的指標。 

          4.另外,除了準確的定位、度量、轉化的邏輯推導外,參考業務目標進行范圍收斂,也是非常重要的工作,它影響著每一個推導環節,以避免偏離產品方向,有效的過濾弱關聯或無關聯的因素。

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          文章來源:站酷   作者:酷家樂UED

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          UI設計原則,看看,有沒有你知道的!

          藍藍設計的小編

          (圖片來源于圖蟲創意)

          1、了解你的用戶

          因為你的用戶是最終評判用戶界面好壞的人,所以用戶即是你的終極目標,不了解用戶需求,即使你的界面做得再好,也不是用戶想要的產品。了解用戶的需求是你開始做界面的前提,試著沉下心來仔細觀察用戶的喜好,并了解他們的技能水平和體驗觀察他們在界面中如何操作。不要迷戀于追逐設計趨勢的更新,或是不斷添加新的功能,始終記住,首要的任務是關注你的用戶,這樣才能創造出一個能讓用戶達成目標的界面。

          2、重視UI模型

          在軟件中,用戶的大部分時間都消耗在界面操作中,比如數據錄入、數據修改、數據查閱等等,這點與瀏覽為主的網站類頁面的用戶操作是完全不同的,所以我們無需畫蛇添足。用戶希望在新創造的界面中看到那些已有的、相似功能的或遵循基本操作方式的軟件界面,即可利用已成慣例的UI模型,使用戶產生親切感。

          3、保持一致

          用戶需要知道一旦他們學會做某項操作,那么下次也同樣可行。語言、布局和設計是需要保持一致性的幾個界面元素。一致性的界面可以讓用戶對于如何操作有更好的理解,從而提升效率。

          4、清晰的視覺層次

          設計時,要讓用戶把注意力放在最重要的地方。每一個元素的尺寸、顏色還有位置,它們為理解界面共同指明了道路。清晰的層級關系將對降低外觀的復雜性起到重要作用。

          (圖片來源于圖蟲創意)

          5、提供反饋

          界面要始終保持和用戶的溝通,不管是他們的行為對錯與否。隨時提示用戶的行為:狀態更改、出現錯誤或者異常信息。視覺提示或是簡單文字提醒都能告訴用戶,他們的行為是否能夠達到預期的結果。

          6、容錯機制

          無論你的設計多么的清晰明了,用戶都會犯錯。你的界面應當允許并要為用戶提供可以撤銷行為的方式,并且對五花八門的輸入數據盡量寬容(沒人愿意只是因為填錯了生日的格式而重頭再來)。同樣,如果用戶的行為引起了一個錯誤,在恰當的時機運用信息顯示什么行為是錯誤的,并確保用戶明白如何防止這種錯誤的再次發生。

          7、鼓勵用戶

          一旦用戶在完成了關鍵操作,可以通過彈出對話框等方式及時告知用戶。值得注意的是,把一個復雜的流程任務分解為若干簡單步驟,將會更顯繁復和讓人精力分散。所以無論正在執行的任務有多么復雜和漫長,在界面上要保持流程的不間斷性。

          8、語言有親和力

          所有的界面或多或少都有文字在其上,讓文稿盡量口語化,而不是華美辭藻的堆砌。為行為提供清晰、簡明的標簽,保持簡樸的文字敘述。。

          9、保持簡潔

          最好的用戶界面就是沒有界面。優秀的軟件界面中,你看不到華而不實的UI修飾,更看不到那些用不到的設計元素。所以當想著是否要在界面上加一個新功能或是新元素的時候,再思考一下:用戶或者界面中真的需要這些么?為什么用戶想要在這里當這個小巧的動態圖標?是否只是因為出于自我喜好和頁面的漂亮而去添加這些元素?優秀的UI工程師做出來的軟件界面不會十分華麗,界面中沒有任何分散用戶注意力打攪用戶操作的元素。甚至應該達到在用戶使用系統的時候完全注意不到頁面和操作復雜的問題,一切都應該是順理成章的。


          (圖片來源于圖蟲創意)

          文章來源:快資訊 作者:德方科技


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

                                                                      微信圖片_20210513163802.png

           

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

           

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務




          vue AES加密(超詳細)

          前端達人

          第一步:

          
          
          1. //安裝
          2. npm install crypto-js --save-dev

          第二步:在src目錄下新建個放公用js文件夾(common),再建一個AES.js文件,例如:

          第三步:在AES.js中填寫如下代碼,key密鑰長度則可以是128,192或256位(默認情況下是128位),正常情況下固定16位數即可

           
          
          1. import CryptoJS from 'crypto-js';
          2. export default {
          3. //隨機生成指定數量的16進制key
          4. generatekey(num) {
          5. let library = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789";
          6. let key = "";
          7. for (var i = 0; i < num; i++) {
          8. let randomPoz = Math.floor(Math.random() * library.length);
          9. key += library.substring(randomPoz, randomPoz + 1);
          10. }
          11. return key;
          12. },
          13. //加密
          14. encrypt(word, keyStr) {
          15. keyStr = keyStr ? keyStr : 'abcdsxyzhkj12345'; //判斷是否存在ksy,不存在就用定義好的key
          16. var key = CryptoJS.enc.Utf8.parse(keyStr);
          17. var srcs = CryptoJS.enc.Utf8.parse(word);
          18. var encrypted = CryptoJS.AES.encrypt(srcs, key, { mode: CryptoJS.mode.ECB, padding: CryptoJS.pad.Pkcs7 });
          19. return encrypted.toString();
          20. },
          21. //解密
          22. decrypt(word, keyStr) {
          23. keyStr = keyStr ? keyStr : 'abcdsxyzhkj12345';
          24. var key = CryptoJS.enc.Utf8.parse(keyStr);
          25. var decrypt = CryptoJS.AES.decrypt(word, key, { mode: CryptoJS.mode.ECB, padding: CryptoJS.pad.Pkcs7 });
          26. return CryptoJS.enc.Utf8.stringify(decrypt).toString();
          27. }
          28. }

          第四步:在需要的地方引入

          import AES from "@/common/AES.js";

          第五步:調用

           
          
          1. // var keys = AES.generatekey(16);
          2. //如果是對象/數組的話,需要先JSON.stringify轉換成字符串
          3. // 不傳key值,就默認使用上述定義好的key值
          4. var encrypts = AES.encrypt(JSON.stringify(cars));
          5. var dess = JSON.parse(AES.decrypt(encrypts));
          6. // var encrypts = AES.encrypt('1234asdasd');
          7. // var dess = AES.decrypt(encrypts);
          8. console.log(encrypts)
          9. console.log(encrypts.length)
          10. console.log(dess)

           

           

          特別提示:當解密的時候是為空的時候(也沒有報錯),那么就一定是你的key長度不符合規范, 可以調整為key長度為16位。

           


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:csdn   

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.

          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務



          關于web項目前后端加密解密總結

          前端達人

          首先項目是基于vue開發的項目

          1、DES加密

          前端

          需要引入js

          import cryptoJs from 'crypto-js'

          // DES加密

          export const encryptDes = (message, key) => {

          return cryptoJs.DES.encrypt(message, cryptoJs.enc.Utf8.parse(key), {

          mode: cryptoJs.mode.ECB,

          padding: cryptoJs.pad.Pkcs7

          }).toString()

          }

          后臺


          package com.huihui.until;

          import java.security.SecureRandom;
          import java.util.Scanner;
           
          import javax.crypto.Cipher;
          import javax.crypto.SecretKeyFactory;
          import javax.crypto.spec.DESKeySpec;
           
          import org.apache.commons.codec.binary.Base64;
           
           
          /**
           * <b>類說明:DES</b>
           * <p>
           * <b>詳細描述:</b>
           * @since 2019年3月31日 下午17:00:16
           */
          public class DESCryptUtil {
              
              private static final String DES = "DES";
              
              public static final String desKey = "ba54ee44";
           
              public static String doEncrypt(String plainMessage, String hexDesKey) throws Exception {
                  byte desKey[] = hexDesKey.getBytes();
                  byte desPlainMsg[] = plainMessage.getBytes();
                  return Base64.encodeBase64URLSafeString(desCrypt(desKey, desPlainMsg, Cipher.ENCRYPT_MODE));
              }
              /**
               * 獲取解密后的字符串
               * @param hexEncryptMessage
               * @param hexDesKey
               * @return
               * @throws Exception
               */
              public static String doDecrypt(String hexEncryptMessage, String hexDesKey) throws Exception{
                  if (hexEncryptMessage == null) {
                      return null;
                  }
                  byte desKey[] = hexDesKey.getBytes();
                  byte desPlainMsg[] = Base64.decodeBase64(hexEncryptMessage);
                  return new String(desCrypt(desKey, desPlainMsg, Cipher.DECRYPT_MODE));
              }
              /**
               * 獲取解密后的數組
               * @param desPlainMsg
               * @param hexDesKey
               * @return
               * @throws Exception
               */
              public static byte[] doDecryptByte(byte[] desPlainMsg, String hexDesKey) throws Exception{
                  if (desPlainMsg == null) {
                      return null;
                  }
                  byte desKey[] = hexDesKey.getBytes();
                  return desCrypt(desKey, desPlainMsg, Cipher.DECRYPT_MODE);
              }
              
              private static byte[] desCrypt(byte[] desKey, byte[] desPlainMsg, int CipherMode) throws Exception{
                  try {
                      SecureRandom sr = new SecureRandom();
                      DESKeySpec dks = new DESKeySpec(desKey);
                      SecretKeyFactory keyFactory = SecretKeyFactory.getInstance(DES);
                      javax.crypto.SecretKey key = keyFactory.generateSecret(dks);
                      Cipher cipher = Cipher.getInstance(DES);
                      cipher.init(CipherMode, key, sr);
                      return cipher.doFinal(desPlainMsg);
                  } catch (Exception e) {
                      String message = "";
                      if (CipherMode == Cipher.ENCRYPT_MODE) {
                          message = "DES\u52A0\u5BC6\u5931\u8D25";
                      } else {
                          message = "DES\u89E3\u5BC6\u5931\u8D25";
                      }
                      throw new Exception(message, e);
                  }
              }
              /**
               * 獲取8位的key
               * @param str
               * @return
               */
              public static String processString(String str) {
                  if(str==null||"".equals(str)) {
                      return "";
                  }
                  StringBuilder sb = new StringBuilder();
                  for(int i=0;i<8;i++) {
                      int index = i<<2&(32-i);
                      sb.append(str.charAt(index));
                  }
                  
                  return sb.toString();
              }
              public static void main(String[] args) throws Exception{
                  DESCryptUtil se=new DESCryptUtil();
                  for (int i = 0; i < 5; i++) {
                      Scanner scanner=new Scanner(System.in);
                      /*
                       * 加密
                       */
                      System.out.println("請輸入要加密的內容:");
                      String content = scanner.next();
                      System.out.println("加密后的密文是:"+se.doEncrypt(content, desKey));
                     
                      /*
                       * 解密
                       */
                      System.out.println("請輸入要解密的內容:");
                       content = scanner.next();
                      System.out.println("解密后的明文是:"+se.doDecrypt(content, desKey));
                  }
              }

          }
           

          2 RSA加密解密

          這是我是在在線生成公鑰私鑰的網站中生成了自己的公鑰私鑰用來測試

          前臺

          import JsEncrypt from 'jsencrypt'

          // RSA加密

          export function encryptRsa(publickey, message) {

          const rsa = new JsEncrypt()

          rsa.setPublicKey(publickey)

          return rsa.encrypt(message)

          }

          后臺

          package com.huihui.until;

          import org.apache.commons.codec.binary.Base64;

          import com.googosoft.config.GlobalConstants;

          import javax.crypto.Cipher;
          import java.security.KeyFactory;
          import java.security.KeyPair;
          import java.security.KeyPairGenerator;
          import java.security.NoSuchAlgorithmException;
          import java.security.SecureRandom;
          import java.security.interfaces.RSAPrivateKey;
          import java.security.interfaces.RSAPublicKey;
          import java.security.spec.PKCS8EncodedKeySpec;
          import java.security.spec.X509EncodedKeySpec;
          import java.util.HashMap;
          import java.util.Map;
            
            
          public class RSAUtil {  
                
              private static Map<Integer, String> keyMap = new HashMap<Integer, String>();  //用于封裝隨機產生的公鑰與私鑰
              public static void main(String[] args) throws Exception {
                  //生成公鑰和私鑰
                  genKeyPair();
                  //加密字符串
                  String message = "df723820";
              //GlobalConstants.PUBLICKEY 公鑰加密
                  String messageEn = encrypt(message,GlobalConstants.PUBLICKEY);
                  System.out.println(message + "\t加密后的字符串為:" + messageEn);

          //GlobalConstants.PRIVATEKEY 私鑰解密
                  String messageDe = decrypt(messageEn,GlobalConstants.PRIVATEKEY);
                  System.out.println("還原后的字符串為:" + messageDe);
              }

              /** 
               * 隨機生成密鑰對 
               * @throws NoSuchAlgorithmException 
               */  
              public static void genKeyPair() throws NoSuchAlgorithmException {  
                  // KeyPairGenerator類用于生成公鑰和私鑰對,基于RSA算法生成對象  
                  KeyPairGenerator keyPairGen = KeyPairGenerator.getInstance("RSA");  
                  // 初始化密鑰對生成器,密鑰大小為96-1024位  
                  keyPairGen.initialize(1024,new SecureRandom());  
                  // 生成一個密鑰對,保存在keyPair中  
                  KeyPair keyPair = keyPairGen.generateKeyPair();  
                  RSAPrivateKey privateKey = (RSAPrivateKey) keyPair.getPrivate();   // 得到私鑰  
                  RSAPublicKey publicKey = (RSAPublicKey) keyPair.getPublic();  // 得到公鑰  
                  String publicKeyString = new String(Base64.encodeBase64(publicKey.getEncoded()));  
                  // 得到私鑰字符串  
                  String privateKeyString = new String(Base64.encodeBase64((privateKey.getEncoded())));  
                  // 將公鑰和私鑰保存到Map
                  keyMap.put(0,publicKeyString);  //0表示公鑰
                  keyMap.put(1,privateKeyString);  //1表示私鑰
              }  
              /** 
               * RSA公鑰加密 
               *  
               * @param str 
               *            加密字符串
               * @param publicKey 
               *            公鑰 
               * @return 密文 
               * @throws Exception 
               *             加密過程中的異常信息 
               */  
              public static String encrypt( String str, String publicKey ) throws Exception{
                  //base64編碼的公鑰
                  byte[] decoded = Base64.decodeBase64(publicKey);
                  RSAPublicKey pubKey = (RSAPublicKey) KeyFactory.getInstance("RSA").generatePublic(new X509EncodedKeySpec(decoded));
                  //RSA加密
                  Cipher cipher = Cipher.getInstance("RSA");
                  cipher.init(Cipher.ENCRYPT_MODE, pubKey);
                  String outStr = Base64.encodeBase64String(cipher.doFinal(str.getBytes("UTF-8")));
                  return outStr;
              }

              /** 
               * RSA私鑰解密
               *  
               * @param str 
               *            加密字符串
               * @param privateKey 
               *            私鑰 
               * @return 銘文
               * @throws Exception 
               *             解密過程中的異常信息 
               */  
              public static String decrypt(String str, String privateKey) throws Exception{
                  //64位解碼加密后的字符串
                  byte[] inputByte = Base64.decodeBase64(str.getBytes("UTF-8"));
                  //base64編碼的私鑰
                  byte[] decoded = Base64.decodeBase64(privateKey);  
                  RSAPrivateKey priKey = (RSAPrivateKey) KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(decoded));  
                  //RSA解密
                  Cipher cipher = Cipher.getInstance("RSA");
                  cipher.init(Cipher.DECRYPT_MODE, priKey);
                  String outStr = new String(cipher.doFinal(inputByte));
                  return outStr;
              }

          }  

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png


          文章來源:csdn   

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務

          element upload 上傳圖片 單獨上傳 和 添加formdata中提交的rules驗證

          前端達人

          lement upload上傳圖片rules的驗證分為單獨提交還是放入formdata中提交

          一個前端小菜雞。若下邊的內容有瑕希望告訴我,如果有更好的方法希望告訴我,感謝萬分。

          這篇文章主要介紹的對el-upload放在表單中提交之前rules的驗證。這里的圖片是必須提交項如果可以不提交可用常用方法直接提交就可以。

          放在formadata表達中提交

          <el-form ref="personform" label-position="right" label-width="120px" :model="formLabelAlign" status-icon :rules="rules"> <el-row> <el-form-item label="簡述"> <el-input type="textarea" v-model="formLabelAlign.paper" autocomplete="off"></el-input> </el-form-item> </el-row> <el-row> <el-form-item prop="file" ref="uploadpic"> <el-upload
                        style="display:inline-block" :limit="2" class="upload-demo" ref="upload" action="/hqx/knowledge/importKnowledge" :before-upload="beforeAvatarUpload" :auto-upload="false" :on-change="imageChange" :on-remove="imageRemove" > <el-button slot="trigger" size="small" type="primary" plain>上傳</el-button> </el-upload> </el-form-item> </el-row> </el-form> <script> import _ from "lodash"; export default { data() { return { xiugai: false, formLabelAlign: { paper: "" }, images: [],// 圖片存儲 rules: { file: [{ required: true, message: "請上傳圖片", trigger: "change" }] }, haspic: false // 默認沒有傳圖片 }; }, methods: { beforeAvatarUpload(file) { // 文件類型進行判斷 const isJPG = /^image\/(jpeg|png|jpg)$/.test(file.type); const isLt2M = file.size / 1024 / 1024 < 2; if (!isJPG) { this.$message.error("上傳圖片只能是 image/jpeg/png 格式!"); } if (!isLt2M) { this.$message.error("上傳圖片大小不能超過 2MB!"); } return isJPG && isLt2M; }, imageChange(file, fileList, name) {//on-change觸發 this.images["file"] = fileList; this.haspic = true; // 如果上傳了就不顯示提示圖片警告 if (typeof this.images.file != "undefined") { if (this.images.file.length > 0) { this.$refs["uploadpic"].clearValidate(); } } }, imageRemove(file, fileList, name) { //on-remove觸發 //如果images為空了說明并沒有提交圖片所以需要顯示警告 if (typeof this.images.file != "undefined") { if (this.images.file.length > 0) { this.$refs["uploadpic"].clearValidate(); } else { this.$refs["uploadpic"].validate(); this.haspic = false; } } }, confirm() {// 提交綁定的事件 if (this.haspic) { // 去掉rules中對圖片的驗證 _.unset(this.rules, ["file"]); this.$refs["personform"].validate(valid => { if (valid) { console.log("說明已經添加了圖片直接提交就行了"); const wfForm = new FormData(); wfForm.append( 'dsc',this.formLabelAlign.paper) Object.entries(this.images).forEach(file => { file[1].forEach(item => { wfForm.append('files', item.raw) wfForm.append(item.name, file[0]) }) }) // 直接提交 } else { console.log("error submit!!"); return false; } }); } else { // 向rules提價一條對圖片的驗證。 _.set(this.rules, "file", { required: true, message: "請上傳圖片", trigger: "change"}); this.$refs["personform"].validate(valid => { if (valid) { console.log("說明圖片沒有提交"); } else { console.log("error submit!!"); return false; } }); } } } }; </script>  
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36
          • 37
          • 38
          • 39
          • 40
          • 41
          • 42
          • 43
          • 44
          • 45
          • 46
          • 47
          • 48
          • 49
          • 50
          • 51
          • 52
          • 53
          • 54
          • 55
          • 56
          • 57
          • 58
          • 59
          • 60
          • 61
          • 62
          • 63
          • 64
          • 65
          • 66
          • 67
          • 68
          • 69
          • 70
          • 71
          • 72
          • 73
          • 74
          • 75
          • 76
          • 77
          • 78
          • 79
          • 80
          • 81
          • 82
          • 83
          • 84
          • 85
          • 86
          • 87
          • 88
          • 89
          • 90
          • 91
          • 92
          • 93
          • 94
          • 95
          • 96
          • 97
          • 98
          • 99
          • 100
          • 101
          • 102
          • 103
          • 104
          • 105
          • 106
          • 107
          • 108
          • 109
          • 110
          • 111

          下邊解釋一下每段代碼的含義:
          1.

          imageChange(file, fileList, name) {//on-change觸發 this.images["file"] = fileList; this.haspic = true; // 如果上傳了就不顯示提示圖片警告 if (typeof this.images.file != "undefined") { if (this.images.file.length > 0) { this.$refs["uploadpic"].clearValidate(); } } }  
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10

          if (typeof this.images.file != “undefined”) 這個可加可不加
          其中的一個原因是因為要頻繁對rules進行操作因為element的el-upload的提示功能在選擇了圖片的時候并不會對圖片的提示進行更改所以只能自己進行操作更改他顯示或者隱藏
          haspic是用來記錄他是否上傳了圖片 如果上傳為true否則為false 在后面提交的時候有用。
          2.考慮到用戶可能會選擇了圖片又刪除了所以加上了一個判斷
          如果在提交的時候進行驗證或者不考慮用戶全部刪除顯示提示可不加

          imageRemove(file, fileList, name) { //on-remove觸發 //如果images為空了說明并沒有提交圖片所以需要顯示警告 if (typeof this.images.file != "undefined") { if (this.images.file.length > 0) { this.$refs["uploadpic"].clearValidate(); } else { this.$refs["uploadpic"].validate(); this.haspic = false; } } },  
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          confirm() {// 提交綁定的事件 if (this.haspic) { // 去掉rules中對圖片的驗證 _.unset(this.rules, ["file"]); this.$refs["personform"].validate(valid => { if (valid) { console.log("說明已經添加了圖片直接提交就行了"); const wfForm = new FormData(); wfForm.append( 'dsc',this.formLabelAlign.paper) Object.entries(this.images).forEach(file => { file[1].forEach(item => { wfForm.append('files', item.raw) wfForm.append(item.name, file[0]) }) }) // 直接提交 } else { console.log("error submit!!"); return false; } }); } else { // 向rules提價一條對圖片的驗證。 _.set(this.rules, "file", { required: true, message: "請上傳圖片", trigger: "change"}); this.$refs["personform"].validate(valid => { if (valid) { console.log("說明圖片沒有提交"); } else { console.log("error submit!!"); return false; } }); } } } };  
          
          • 1
          • 2
          • 3
          • 4
          • 5
          • 6
          • 7
          • 8
          • 9
          • 10
          • 11
          • 12
          • 13
          • 14
          • 15
          • 16
          • 17
          • 18
          • 19
          • 20
          • 21
          • 22
          • 23
          • 24
          • 25
          • 26
          • 27
          • 28
          • 29
          • 30
          • 31
          • 32
          • 33
          • 34
          • 35
          • 36

          提交的時候進行判斷。因為沒有想到其他的方法所以寫了一個變量判斷是否在rules加上對圖片的判斷。因為如果存在對圖片的判斷。form驗證的時候就總是throw error 不能進行提交操作this.$refs[“personform”].validate(valid){}是提交form表單的時的驗證
          (1)在有圖片的時候去掉對圖片的驗證
          (2)在有圖片的時候加上對圖片的驗證

          不放在formdata中提交(相對于上一個這個簡單多了)

          <template> <div> <el-form ref="personform" label-position="right" label-width="120px" :model="formLabelAlign" status-icon :rules="rules"> <el-row> <el-col :span="12"> <el-form-item label="發布人"> <el-input
                          size="mini" v-model="formLabelAlign.person" autocomplete="off" clearable :disabled="xiugai" ></el-input> </el-form-item> </el-col> </el-row> <el-row> <el-form-item label="簡述"> <el-input type="textarea" v-model="formLabelAlign.paper" autocomplete="off"></el-input> </el-form-item> </el-row> <el-row> <el-form-item prop="file" ref="uploadpic"> <el-upload  
          

          style="display:inline-block" :limit="2" class="upload-demo" ref="upload" action="/hqx/knowledge/importKnowledge" :before-upload="beforeAvatarUpload" :auto-upload="false" :on-change="imageChange" :on-remove="imageRemove" :on-success="onsuccess" > <el-button slot="trigger" size="small" type="primary" plain>上傳</el-button> </el-upload> </el-form-item> </el-row> </el-form> </div> </template> <script> import _ from "lodash"; export default { data() { return { xiugai: false, formLabelAlign: { paper: "" }, images: [], rules: { file: [{ required: true, message: "請上傳圖片", trigger: "change" }] }, haspic: false // 默認沒有傳圖片 }; }, methods: { beforeAvatarUpload(file) { // 文件類型進行判斷 const isJPG = /^image\/(jpeg|png|jpg)$/.test(file.type); const isLt2M = file.size / 1024 / 1024 < 2; if (!isJPG) { this.$message.error("上傳圖片只能是 image/jpeg/png 格式!"); } if (!isLt2M) { this.$message.error("上傳圖片大小不能超過 2MB!"); } return isJPG && isLt2M; }, imageChange(file, fileList, name) { this.images["file"] = fileList; this.haspic = true; // 如果上傳了就不顯示提示 if (typeof this.images.file != "undefined") { if (this.images.file.length > 0) { this.$refs["uploadpic"].clearValidate(); } } }, imageRemove(file, fileList, name) { if (typeof this.images.file != "undefined") { if (this.images.file.length > 0) { this.$refs["uploadpic"].clearValidate(); } else { this.$refs["uploadpic"].validate(); this.haspic = false; } } }, onsuccess(response, file, fileList){ // 如果提交失敗將haspic改為false后邊的數據就不讓他提交 }, confirm() { if (this.haspic) { // 去掉rules中對圖片的驗證 _.unset(this.rules, ["file"]); this.$refs["personform"].validate(valid => { if (valid) { console.log("說明已經添加了圖片直接提交就行了"); const wfForm = new FormData(); wfForm.append( 'dsc',this.formLabelAlign.paper) //直接將wfForm提交就可以 } else { console.log("error submit!!"); return false; } }); } else { alert('請添加圖片之后在提交') } } } }; </script>

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png

          文章來源:csdn   

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          nodejs 接收上傳的圖片

          前端達人

          1.nodejs接收上傳的圖片主要是使用formidable模塊,服務器是使用的express搭建。

          引入formidable

          var formidable = require('./node_modules/formidable');

          攔截請求,設置formidable的常規項

          復制代碼
          app.post("/image",function (req,res) { var form = new formidable.IncomingForm();
              form.encoding = 'utf-8';
              form.uploadDir = path.join(__dirname + "/../page/upload");
              form.keepExtensions = true;//保留后綴 form.maxFieldsSize = 2 * 1024 * 1024;
          
          });
          復制代碼

          解析圖片,重命名圖片名稱,返回給前端

          復制代碼
           //處理圖片  form.parse(req, function (err, fields, files){
                  console.log(files.the_file); var filename = files.the_file.name var nameArray = filename.split('.'); var type = nameArray[nameArray.length - 1]; var name = ''; for (var i = 0; i < nameArray.length - 1; i++) {
                      name = name + nameArray[i];
                  } var date = new Date(); var time = '_' + date.getFullYear() + "_" + date.getMonth() + "_" + date.getDay() + "_" + date.getHours() + "_" + date.getMinutes(); var avatarName = name + time + '.' + type; var newPath = form.uploadDir + "/" + avatarName;
                  fs.renameSync(files.the_file.path, newPath); //重命名 res.send({data:"/upload/"+avatarName})
              })
          復制代碼


          完整代碼如下

          
          
          var path = require("path"); var fs = require("fs"); var express =require("./node_modules/express"); var app=express(); var bodyParser = require('./node_modules/body-parser'); var formidable = require('./node_modules/formidable');
          app.use(bodyParser.json());
          app.use(bodyParser.urlencoded({extended: true}));
          app.use(express.static(__dirname + "./../page"));
          app.listen("8083",function () {
              console.log("服務啟動")
          }); //攔截請求 app.post("/image",function (req,res) { var form = new formidable.IncomingForm();
              form.encoding = 'utf-8';
              form.uploadDir = path.join(__dirname + "/../page/upload");
              form.keepExtensions = true;//保留后綴 form.maxFieldsSize = 2 * 1024 * 1024; //處理圖片  form.parse(req, function (err, fields, files){
                  console.log(files.the_file); var filename = files.the_file.name var nameArray = filename.split('.'); var type = nameArray[nameArray.length - 1]; var name = ''; for (var i = 0; i < nameArray.length - 1; i++) {
                      name = name + nameArray[i];
                  } var date = new Date(); var time = '_' + date.getFullYear() + "_" + date.getMonth() + "_" + date.getDay() + "_" + date.getHours() + "_" + date.getMinutes(); var avatarName = name + time + '.' + type; var newPath = form.uploadDir + "/" + avatarName;
                  fs.renameSync(files.the_file.path, newPath); //重命名 res.send({data:"/upload/"+avatarName})
              })
          });

          
          
              

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png

          文章來源:博客園

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 平面設計服務

          用理性思維做情感化設計

          資深UI設計者

          分享框架

          唐·諾曼提出了情感化設計的3個方向:本能層、行為層、反思層。但如何在一個項目中,通過情感化設計,讓用戶切實感受到這樣的情緒,一直沒有很系統的理論。恰逢58同城交友業務中有這樣的項目,可以實踐一下這方面的思考。本次活動中,嘉賓分享了直播禮物的價值與意義、直播情境情緒,并以此為基礎,探討了理性化搭建情感化禮物的設計體系。

           

          第一部分:直播禮物的價值與意義

          禮物的價值是什么?有什么意義,為什么不直接用錢?禮物和金錢的不等價感受,決定了禮物是很好的消費載體;不同場景需要不同載體,禮物的多樣性滿足了不同場景的需求;直接送錢可能會讓用戶不爽。

           

          第二部分:直播的情境和情緒(含案例)

          禮物要匹配情境情緒出現,送錢也不太合適,而當前平臺已存在30多款禮物,但是用戶的使用次數較少,期望通過本次項目更新直播間的禮物,并提升ROI。因此需要重新探索直播間會出現的情境情緒,并設計與之匹配的禮物。

          這款產品面向下沉市場、25~40歲、單身/離異的用戶群體。

          設計情感化禮物的靈感來自于彼得·MA·德斯梅特的理論模式。

          情感產生的過程:用戶對產品的關注點和產品所呈現的信息相結合會引發用戶對產品的評估,而評估的結果會最終決定用戶對產品的情感是什么樣子的。由于個體的動機、價值觀、態度的不同,情感產生的差異是不可控的,導致設計師在設計的時候處于一個相對被動的位置。因此期望可以為設計師提供一些方向性的指引,幫助他們更好地完成產品的設計。因此通過模型推導,了解用戶對產品的情感和關注點,從而推導出產品應該呈現什么樣的信息,從而幫助設計師做出更好的設計。

          2.1 規劃思路:

          • 有計劃地考量使用者的情感反應,從而影響使用者對產品的評估,最終達到更好地建立產品與使用者的情感聯系的目標。

          2.2 實施步驟:

          1. 階段一:搭建情感指標
            在產品從0到1階段,快速產出禮物,因此通過前人研究、競品分析、頭腦風暴等手段產出情感指標。
          2. 階段二:核準情感指標
            產品上線后,通過對真實用戶的調研,對第一階段提出的情感指標進行精準的核準。

            1) 前人研究
            以代爾夫特大學積極情感指標為理論基礎,但因為它不帶任何業務屬性,因此無法直接使用。

            2) 頭腦風暴
            為了將基礎情緒體驗轉化為業務屬性的情感指標,進行第二步的頭腦風暴。邀請設計師、直播的產品經理進行討論,根據對業務理解+目標用戶特征+使用場景+行為目標綜合考慮,從基礎的正面情感表中篩選出適合的指標。

           

          基于上述結論,給到設計師合理的方向性指引,快速上線了一部分禮物。在產品逐漸趨于成熟之后,需要對最初建立的情感指標進行核準,了解真正用戶在使用過程中對產品的情感訴求和關注點,進一步調整情感。

          通過1V1電話訪談,對11名真實用戶進行了深訪。

           

          在階段二中,主要探討了以下四點:

          1. 使用動機:
            理解用戶的使用動機,能幫助我們更好得理解用戶,設計好產品,刺激用戶做出我們想要的行為;
          2. 送禮場景:
            洞察用戶送禮場景,分析用戶的情感需求和功能需求,幫助我們提供更合適的禮物;
          3. 影響因素:
            主要目的在于探討禮物本身應該具備的因素,以及在送禮過程中如何刺激用戶送禮;
          4. 對禮物的期待:
            探討未來禮物可優化的方向。

          結合上述分析,提煉出了情感訴求和產品關注點兩個層面的信息。情感訴求層面,通過送禮場景和送禮動機的分析,將原來的5個情感指標重新定義為3個情感指標:自豪、愛慕、情欲。這3個情感指標將成為后續建立禮物庫的基礎。

          產品關注點層面,從功能、體驗層面為設計師提供了方向性的引導。

          用研通過上述一系列的研究和分析,僅僅可以給設計師一些方向性的引導,設計師在設計層面需要進一步結合分析結論進行拆解和設計。

           

          第三部分:理性化思維,搭建情感化設計體系

          意象的概念闡述

          • 名詞釋義:客觀事物經過創作主體獨特的情感活動而創造的一種藝術形象。
          • 簡單理解:設計師通過自己生活情感的特有體驗,進行藝術加工后創造出來的形象。

          情緒與意象具有一定的關聯性,它可能是生活習得的。例如:秋雨、孤獨的老人、掩面哭泣等都可以表達悲傷;又或者是被競品教育的,例如:火箭、跑車等,用于表達自豪,均是來自競品的教育。

          3.1 剝離意象維度

          我們可以從情緒誕生的場景來剝離構成意象的維度:

          • 以形象為內核、主體,在設計維度進行剝離時,可以有形象、材質、顏色等元素;
          • 向外一層,即此主體所處的場景,包含光效、聲音、時間等元素;
          • 再向外一層是關系,即形象如何展示在場景中,包含動效、節奏等元素。

          3.2 收集具體意象

          基于上述維度及元素,設計、產品、運營團隊內收集意象,主要方式包括以下兩類:

          1. 還原場景
            構建場景 → 填充故事 → 提取禮物
          2. 角色演繹
            提煉產品相關8個角色,并隨機分配個同事 → 收集角色影響 → 角色演繹 → 禮物聯想

          另一方面,也要收集競品的意象,同時需要將前面頭腦風暴產生的意象以及競品的意象進行形象類型、禮物形態、價格定位的分析和提取。

          3.3 構建情緒意象庫

          以此為基礎,可以構建情緒意象庫。某一種形象,在不同的場景和不同的關系下,可以表達不同的情緒。例如同樣是煙花,小仙女棒式的煙花和宏偉的漫天綻放的煙花所表達的情緒是截然不同的。因此我們根據所要表達的情緒,將所對應的形象、場景、關系收納到對應的意象庫中,這可以幫助一些視覺設計師快速給出設計方向。

          3.4 處理意象的設計形態

          下一步,即可為意象進行設計形態的處理。我們將需要處理的意象,以單一-復合 和 具體-抽象 為坐標進行了分類,從而劃分小禮物、中禮物、大禮物,以提供定價參考。

          3.5 構建情緒意象的視覺語言

          由于直播間涉及的禮物品類繁多,同時參與設計的視覺同學也較多,為了使得最終的產出有視覺風格上的一致性,針對每一種情緒進行了配色、光效、樣式、質感上的定義。

          3.6 禮物定價

          禮物定價趨勢方面,對競品的禮物進行了分析,將競品的禮物按表達的情緒聚合,并分析在這種情緒上,禮物價格的分布,來幫助我們了解競品針對不同情緒表達的禮物的定價規則,以指導自己產品的定價。

          最后,禮物上線后,銷售量top10的禮物中,新禮物占比達到60%。同時同檔位中效益最好的一款,收益提升了1035.4%。

          以上是關于理性思維搭建情感化設計體系的分享。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          文章來源:UXRen   作者:寶珠

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          為什么“智能”不是品牌差異化定位?

          資深UI設計者

          編輯導語:面對行業競爭、市場環境的發展與用戶需求的提高,品牌若想在眾多同行中脫穎而出,就需要對自身做好定位,以求給消費者留下深刻印象?!爸悄堋币辉~近來頻繁出現,然而“智能”真的可以成為品牌定位標簽嗎?我們對“智能”又該如何理解呢?

          2019年12月份,著名主持人蔡康永與著名經濟學家薛兆豐正面交鋒,他們的議題是:智能,到底“能不能”?雙方各持一詞,爭鋒不相上下。關于“智能”的優缺點,每個人的論證都非常精彩,且令人信服。

          這場關于“智能”的討論,熟對熟非?可能沒有明確的答案。但憑此一點就可以證明:“智能”絕對是21世紀,商業界最流行的概念。

          “智能”這個詞無論放在哪個行業都是科技感的象征??此迫魏纹放浦灰诋a品中加上“智能”概念,就掌握了致勝砝碼。

          最近,我們到南孚集團內訪,在與他們的高管進行交流中,他們講,他們針對智能家居開發一款電池產品,并考慮把這款電池定義為“智能電池”。很慶幸,他們最終放棄了。

          沒有一點點防備,沒有一絲顧慮,“智能”已經潛入我們的生活。當你走進家電賣場,幾乎找不到不是智能的家電。你也可以到家居建材賣場走一圈,映入眼簾的是智能水龍頭、智能馬桶、智能鎖、智能玻璃、智能蒸箱、智能家居、智能電梯、智能廚衛、智能晾衣架、智能美甲機……無處不在的智能。

          我們的生活已經被“智能”包圍了。

          智能手機的普及讓人們意識到“智能”的先進性與方便性,此后便一發不可收拾,大量的智能設備走進人們的生活。起初,智能只在家電行業流行,然后逐步滲透到家居建材行業。發展的今天,只要與電相關的設備都智能化了。因為企業相信,“智能”概念能夠幫助到他們。

          武漢一家電梯企業直接把“智能”申請成商標。

          總而言之,我們所處的商業環境正處于“智能”的變革中。對于企業來說,“智能”既是挑戰也是機遇。他們把“智能”作為廣告設計的主角,并認為“智能”應該是傳播的核心,甚至比品牌還重要。

          在蘇州,有一家企業在公路大牌廣告中說“智能是我們的方向”。這家企業甚至沒有把自己的品牌放進廣告中,也沒有自己在銷售什么產品。

          中山市一家智能安防企業,它在廣告中說“智能在門上飛馳”。

          浙江維衛電子潔具有限公司在廣告中說“買智能,選維衛”。這個廣告在上海虹橋高鐵站投放至少2年。

          站在企業角度就能理解他們的做法。在智能浪潮襲來之時,他們非常害怕自己的產品成為過時貨。為了使產品成為人們關注的焦點,就必須與智能搭上關系。

          企業認為,當消費者瀏覽網頁,觀看產品說明書,在購物平臺看相關的體驗評價,在與消費者的每次互動中,只要把“智能”一詞送入消費者眼簾,產品必然比以往賣得好。

          企業對“智能”的追求可謂到了瘋狂的地步。從創建品牌角度看來,“智能”會成為品牌差異化的定位嗎?

          不急于回答這個問題,我們探究一下“智能”是否會增加品牌的競爭力。

          一、智能缺乏競爭力

          “智能”是傳統企業的興奮劑。尤其是這個時代,傳統企業不被淘汰的救命稻草就是抓住智能風口。因為“智能”會讓他們的產品看起來很高級。

          投資者也致力于尋找這樣的企業,并期待下一個“獨角獸”的誕生。媒體也會挖掘他們的故事,并把他們帶到聚光燈下。

          對于一個企業來講,“智能”到底是機遇?還是冒險?

          我們看幾個實踐案例,他們都是“智能”概念的簇擁。據我們觀察,不同企業的實踐成效也不盡相同。部分企業的實踐卻帶來災難性的后果;有些企業在實踐一段時間之后便放棄了;還有的企業正在實踐中……

          我們看一個傳統企業的實踐案例。從結果來看,“智能”概念并沒有讓它的品牌變得更強大。相反,“智能”引導這家企業走向了極端。

          浩沙原本是全國領先的健身房連鎖機構。到了智能時代,他們已經迫不及待把“智能”與健身房結合在一起。他們通過APP把智能硬件和健身房進行一體化建設,并宣布1億元戰略投資健身APP啡哈健身。同時,內部孵化的硬件公司鈦酷科技,開始健身智能硬件的研發。

          智能健身房受到媒體的關注,他們大肆鼓吹智能健身房的到來。人民網以《浩沙推出大健身戰略打造一流智能化健身房》為主題發表看法,新華社發文《新零售健身時代來了 浩沙啟動首家智能健身會所》。

          實際上,浩沙智能健身房并沒有因此而不可戰勝,而是一步一步消失在人們的視線中。

          從競爭角度來看,即便“智能”概念沒能提升品牌的競爭力,但也不至于導致浩沙健身失去競爭力。導致浩沙走向衰落的原因在于,浩沙把“智能健身館”當作企業的核心戰略,并為此提供相應的戰略支持。

          直白的講,他們為“智能健身館”投入太多。如此大的投入卻沒有吸引新的顧客,導致企業資金鏈斷裂,走向破產。

          再看另一類企業的實踐,他們試圖通過“智能”概念與競爭對手實現區隔,從而創造新顧客。但事與愿違,而后因為實踐效果微乎其微而放棄。

          中國廚房電器領導品牌老板電器為了迎合趨勢,于2014年9月發布全球首臺搭載ROKI系統的智能大吸力油煙機,并暢想行業未來的發展趨勢:智能化與科技感成為主流。

          在老板電器預見的智能世界里,吸油煙機內部嵌入攝像頭可以成為標配,它既可以實時視頻通訊,又可以遠距離監控烹飪狀態。

          智能手環精準記錄人體的運動量和身體狀況,將這些數據與菜譜的葷素搭配,卡路里和維生素的比例都結合在一起,智能推送菜譜,保證營養與能量的均衡。

          同樣的實踐,2016年,中國電動自行車領先品牌雅迪在上海國際時尚中心正式發布公司首款智能電動車新品——雅迪Z3。

          所謂智能,就是說雅迪Z3擁有自己專屬的智能手機APP,騎乘者通過APP可以輕松地對電動車進行操控。雅迪Z3的APP支持GPS和北斗實時雙模定位、遠程報警、智能診斷、開機自檢、服務網點搜索、一鍵切換動力模式以及車輛個性化設置等功能。

          老板和雅迪兩家企業很快就在傳播層面放棄了“智能”概念。

          可能的原因是實踐效果不佳。

          雅迪和老板的實踐并沒有引起其他企業的企業警惕。相反,部分企業會認為雅迪和老板的成功是因為他們向消費者傳達了“智能”概念。

          實際上,在兩個品牌訴求“智能”之前,雅迪電動車和老板電器已是行業領先品牌,智能并沒有給他們增色,也沒有讓兩個品牌的影響力得以提升。

          話說回來,智能也沒有讓他們的品牌失去影響力,只是瞎折騰了一番。對于這個具有巨大領先優勢的品牌而言,消耗一些資源并不會令他們傷筋動骨。

          近幾年,“智能”如瘟疫一樣侵入汽車市場。如果你經常出入各種車展,就不難發現幾乎所有的車企都將重點放在了“智能”領域并紛紛將“智能”作為汽車重要的亮點。小鵬、蔚來、理想和威馬這四個領先品牌如何定義自己的品牌?

          • 威馬:智能汽車頭號實力派;
          • 小鵬:更懂中國的智能汽車;
          • 理想:更自由的智能電動車;
          • 蔚來:智能電動全能SUV。

          很明顯,他們一致地把目光鎖定到“智能”概念上,并竭力占據它,從而實現品牌的差異化。然而企業應該深度思考的是,對于消費者而言,什么是“智能汽車”?“智能”到底意味著什么?如何定義“智能汽車”呢?信息顯示:

          智能汽車是一個集環境感知、規劃決策、多等級輔助駕駛等功能于一體的綜合系統,它集中運用了計算機、現代傳感、信息融合、通訊、人工智能及自動控制等技術,是典型的高新技術綜合體。

          目前對智能汽車的研究主要致力于提高汽車的安全性、舒適性,以及提供優良的人車交互界面。

          顯然“智能汽車”意味著眾多好處。

          這與智能手機發展的最初階段頗為相似。智能手機擁有眾多好處,但沒有哪個品牌能夠占據“智能手機”。那些強大的品牌都是通過占據攝影、信號、音樂、快充等概念來實現區隔。

          由此類推,電動汽車品牌不可能通過占據“智能”創建定位,他們實現差異化的方式應該是占據其它的詞匯,而不是智能。

          從方法論來講,定位理論倡導品牌占據一個明確的,單一的詞匯。而“智能”呈現的卻是包羅萬象,好處眾多。這顯然違背了定位理論的基礎。

          雖然“智能”不會成為汽車品牌的定位概念,但汽車朝著智能化方向進化卻不容忽視,因為它讓人們的出行更加便捷、更加安全、也更加舒適。如果你的汽車不具備智能化,可能面臨被淘汰的局面。

          從競爭角度來看,答案是顯而易見的——智能沒讓品牌變得與眾不同,變得更有競爭力。

          二、智能無法被定義

          消費者認為什么是智能?它能提供什么價值?對于那些致力于通過智能創建定位的企業而言,這可不是一個可有可無的問題,而是一個首先要弄清楚的問題。否則,企業如何在心智中占據它。

          這個問題并不容易回答。我們試圖從認知科學領域尋找答案,但依然模棱兩可。

          哈佛大學認知心理學家史蒂芬?平克曾在《心智探奇》中討論過“什么是智能”。平克先生在了解其他心理學家對“智能”的看法后,他說出了自己的看法。他認為,智能是面對阻礙,根據理性規則做出決策,從而達到目標的能力。

          許多心理學家及認知科學家對“智能”的定義迥然不同。由此可以看出,到目前為止,人們對“智能”依然缺少統一的定義。

          企業真應該回過頭來想一想,到底什么才算是智能?單從定義上講,似乎都難以找到一個準確答案。因為一旦將這個詞放在任意一個產品上,其定義都會發生變化。

          在油煙機品類中,智能代表的含義是:可視頻通訊,遠程監控烹飪狀態。智能手環精準記錄人體的運動量和身體狀況,將這些數據與菜譜的葷素搭配,卡路里和維生素的比例都結合在一起;智能推送菜譜,保證營養與能量的均衡。

          在電動自行車品類中,智能代表的含義是:支持GPS和北斗實時雙模定位、遠程報警、智能抱死、藍牙感應、服務網點搜索、電池檢測以及車輛個性化設置等功能。

          在馬桶品類中,智能代表的含義是:通過按鈕面板來進行操作臀部清凈、下身清凈、移動清凈、坐圈保溫、暖風烘干、自動除臭、靜音落座等等。消費者在使用的時候,只要手握遙控器輕輕一按,所有功能都可輕松實現。

          老板智能大吸力油煙機、雅迪智能電動車以及智能馬桶……如果把名單列全,數量可能會令人吃驚。

          不同行業,智能代表著不同的定義。即便處于同一品類,消費者對“智能”的理解也因人而異??梢酝茰y,這些定義傳遞到消費者那里,他們定然不知所措。

          消費者如何理解“智能”?它的價值在哪里?

          如果把這個問題拋給消費者,他們肯定一臉無辜。商業界創造出來的詞匯,為什么讓我們來解釋呢?根本原因在于,商業界對智能的定義千差萬別,導致消費者接受到的信息非常凌亂。

          我們對購買智能產品的消費者進行了訪談。結論是,消費者對“智能”的理解是模糊的,不清楚“智能”到底能夠帶來了什么好處。那些花里胡哨的功能,他們并不在乎。

          非但如此,在實踐中,許多企業的“智能”概念抹殺了一個犀利的差異化定位。

          我們做過一項調研,當向消費者介紹指紋鎖時,很容易就理解了。然而,當我們詢問他們對智能鎖的看法時,他們開始猶豫不決。在不確定的語氣中,有的消費者說是指紋開鎖,有的消費者說是密碼開鎖,還有的消費者說是臉部識別開鎖。

          企業的想法是越多越好,僅訴求指紋鎖,好像漏了一項功能;僅訴求密碼鎖,好像也漏了一項功能?!爸悄苕i”成為他們的解決方案。

          可以看出 “智能”是一項復雜的功能。

          當企業把眾多功能用“智能”概括時,沒有讓事情變得簡單,反而更加復雜。如果你不能用一句話向消費者說清楚品牌的優勢所在,即便再先進的功能也不能創造價值。

          企業要弄清是什么使您的品牌與競爭對手區分開來。聚焦單一功能才有可能創建品牌。2017年,定位之父艾·里斯先生在第三屆定位峰會上發表演講時表示:“企業創建品牌應該聚焦單一功能”。

          也就是說,品牌聚焦“智能”中的某一項功能或許可以創建一個定位。從功能角度來看,“智能”在一定程度上抹殺了一些有價值的功能,從而導致企業錯失通過聚焦單一功能來創建品牌的機會。

          幸好老板電器放棄了“智能油煙機”,并明智地回到“大吸力”定位。長期聚焦“智能”概念可能會導致品牌的戰略成果不及現在。

          克里夫定位學院的一家學員企業,他們的學習機有一項非常獨特的功能,在我們看來,這項功能非常有價值,憑借此項功能完全可以創建一個全新的品類。可惜的是,這個產品還有其他諸多功能。

          企業管理者陷入了“多功能”產品的怪圈,他們用一個時髦的概念概括了產品的功能,這個詞就是“智能”。

          每當企業管理者向他人介紹這款產品時,用30分鐘,說了許多功能,但聽者越來越迷惑。

          放棄“智能”回歸原有定位的案例并不少見。有個企業的實踐經歷令我們印象深刻。2017年,第十二屆豫商大會后,李亮院長和我一同與廣東名門鎖業董事長陳力先生乘車回酒店。在路上,陳力先生講,名門在2016年走了一段彎路。

          他們認為“智能”在未來會比“靜音”更有競爭力。

          因此,名門開始聚焦于“智能”。為了搶占“智能門鎖”,他們投入不少資源。但最后發現,品牌并沒有因此變得更好。競爭壓力迫使他們回歸“靜音”。

          企業管理者一定要謹記,一旦公司開發出一項新功能,千萬不要把這個功能與其他功能混合在一起,然后給它一個時髦的“智能”概念。

          讓品牌與眾不同的最佳的策略是聚焦單一功能。

          三、平淡無奇的概念

          品牌創建與產品設計有很大的不同。

          設計產品時,當企業發現某項新技術有競爭力,企業就可以獲取,從而增強產品的競爭力;創建品牌關乎心智,當一個概念充斥在商業界并隨即可見時,心智便認定它不再重要,從而導致品牌占據這個概念的價值大大減弱。

          就現在的商業環境而言,“智能”已隨即可見。在認知中,它已平淡無奇。

          一個適用于所有行業,適應于所有品牌的概念必然會失去它鋒利的一面。“智能”之所以能適用如此多的行業,就是因為它是一個很寬的概念。寬泛概念對于創建品牌通常沒有什么價值。

          事實上,目前還沒有一個品牌能夠通過占據“智能”來實現區隔,未來也不會有。

          我們的觀點是“智能”不能成為品牌之間的區隔概念。但智能也并非一無是處,它會使人們的生活變得便捷,變得幸福。雖然它對創建品牌的作用不大,但它依舊是產品進化的主要方向。一旦企業的產品在智能化方面落后于競爭對手,它就很容易在心智中與“過時貨”劃上等號。

          眾所周知,特斯拉是全球純電動汽車的絕對領導者。研究特斯拉的過去會發現,特斯拉沒有在某個階段聚焦于“智能”。但這并不意味著特斯拉沒有超智能方向進化,相反,特斯拉是該領域智能化程度最高的品牌。

          產品競爭力和品牌差異化具有很大的不同。智能是產品進化方向,可以增加產品競爭力,是產品參與市場競爭的必要條件。但“智能”添加到品牌概念中,并不會在心智中被占據,也不會讓品牌差異化。

          本文通以以上觀點來表明我們的看法,即:在品牌創建定位中,“智能”發揮的力量微乎其微。這一觀點可能會遭到同行及企業的“白眼”。但我們會堅持自己的看法。

          傳統品類貼上“智能”標簽總是很吸引人,讓企業放棄太難了。只要企業萌生通過“智能”創建品牌定位的念頭,這些論據及觀點都不值一提。在商業界,想必還會有更多的企業踏進“智能”怪圈并無功而返。


          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          文章來源:人人都是產品經理   作者:朱小栓

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          如何講述你的設計

          ui設計分享達人

          在工作中常常被問到如何表達講述自己的設計,為了讓自己的設計有理可依,對接上下游匯報工作的時候,總結以下一些方法和觀點,幫助不知從何講述自己設計的人一些語言技巧。  

          以下僅是個人觀點,用作探討交流,文中所有舉例均為本人工作設計輸出。

          設計師能做出好的設計,卻缺乏系統化的語言包裝,“如何講設計”不該讓它成為難題,做一個有產品思維的設計師,讓你的設計以理服人,我們要不止停留在視覺表層,更要從多緯度看待產品設計,本文將從以下三點簡述:01.產品設計的五個層面,02.講述設計的流程,03.關于本次總結

          做好產品設計的第一步,是了解產品, 要對于產品的需求如何確定、產品定位如何決定有一個基本的認識,在產品常識里面最重要也最常用的就是產品設計的五個層面,也簡稱用戶體驗五要素——

          作為UI設計師,所處的視覺設計是表現層,是確定產品的最終形態,因此也處于產品設計的頂層(能被看到),是一個具象畫的呈現;其次,往里推框架層,是確定產品外觀,將界面信息和導航設計有序歸類,讓用戶使用或者理解;結構層是為用戶設計一個結構化的體驗,將零散的元素轉化為有序立體的空間;范圍層確定產品的功能和需求;最后戰略層是確定產品目標和用戶需求;底層邏輯結構決定上層意識形態表現,因此在設計前我們要知道產品是屬于洞察階段,設計中是屬于產品設計解決方案階段,整體的產品設計是一個概念通過無數個層面的努力,經過時間,轉化為具象表現的過程,所以我們在完成一項設計時,應該講述一個完整的設計思路 ,不要讓自己的設計思路僅停留在表面。

          整個產品的設計產出是一個抽象到具象化的過程,設計的前期屬于產品洞察階段,這個時候一般由團隊的老板領導結合當下市場需要,有用戶的需求就有商機,想出產品大致的方向(戰略層)然后通過產品經理整合梳理高層的意見確定產品大致的功能和內容輸出原型(范圍層),交給交互設計師優化產品細節邏輯和信息具體框架,經過研發評估能夠技術實現產出交互稿(結構、框架層),這里已經過渡到設計解決問題執行階段,最后是給到界面設計師美化視覺產出高保真(表現層)。

          也就是到我們自己設計輸出之前要經歷這么多,如果能在講述自己設計的時候,提前去了解這些,那么設計內容就不愁沒法兒講,光是闡述自己的設計思路就可以講出一個故事,這也是為什么現在很多品牌賣貨都開始營銷產品背后的故事由來。我們設計能做好,也要會用語言推銷自己的設計成果。

          設計是對于某件事精心準備的過程。好的設計作品,應該擁有完整的設計流程,因此我們在講述自己設計作品的時候,有一套完整系統化的方式是非常有效的。完整的設計流程包含以下4個步驟:

          第一是我們需要去了解設計的需求背景,知道大概的方向—— 

          1. 來源(簡單理解就是誰提出的問題)需求有可能是你的老板、你的產品經理、或者交互設計、或者視覺上的問題··· 

          2. 背景(籠統一點,就是這個需求是新需求還是原來有然后進行改版優化)需求的基層性質是什么,原本調性是什么,我們要做什么樣的產品··· 

          3. 目標(目標一般都是需要解決什么問題)搞清楚為什么做這個需求,能解決什么痛點,不做無用功。

          誰提出的問題,是新的需求還是舊的問題,或者我們要解決什么?圍繞這幾個方向將你的設計概述出來,會讓非專業的人也能聽懂你做了什么,舉個簡單的例子,我們公司后臺一個很小的產品bug需求,往往這種需求就是產品經理的一個截圖和他標注的兩句話——

          然后你完成了這個需求單,在傳達給非產品經理以外的人的時候,你有可能是以下轉述方式——

          毫無疑問,你就是將需求者的意思一字不落的轉達了,但是對于其他的聽者來說,你的轉述平平無奇、毫無意義,甚至都沒有印象你做了什么,所以你應該講清楚這個需求的背景—— 

          設計需求來源是誰,原本屬于產品哪個模塊(來源),他原來功能是怎么樣的,界面上展示的結構哪里有問題(背景),視覺用了什么樣的方式改成什么樣,解決了什么痛點(目標)

          講清楚誰給的需求,需要解決什么問題,是在原來的基礎上不變動邏輯的情況下增加了什么達到了什么目的,才讓你的敘述更完整,聽起來更有邏輯。如果是一項新的需求,沒有背景,那還得從設計分析說起,設計分析就是讓你更專業的去做事,設計分析分為——用戶分析,設計目標,和設計手段三個要點:

          首先用戶分析就是,分析你做的東西給誰看,而用戶又分為群體用戶和獨立用戶,在c端常見的就是獨立用戶,他們通常不定性,且有很多特征;在b端,目標用戶一般是群體,他們大多數是有場景特性和行業特性,針對獨立用戶和群體用戶,我們得出的用戶特征、基本信息、需求結論也是不一致的,所以我們應該結合產品的調性分析一下我們做出來的設計究竟給誰看給誰用。常見的用戶分析方法有:用戶畫像、用戶訪談、問卷調查、焦點小組、眼動測試、用戶反饋以及大數據分析,這些方法中最簡單的是用戶畫像,就是舉實際的例子列出真實用戶的特征信息及使用場景。B端用戶分析方法常用大數據分析和用戶反饋,這兩種方式通過對接需求的上下游就可以得知。

          通過用戶分析得出需求結論,滿足需求就能達成設計目標——

          設計目標結合卡諾模型來分析,卡諾模型—反應產品性能和解決用戶需求的滿意度的一種非線性關系,具體想了解的可以自行百度,站在巨人的肩膀上我們看得更遠。 卡諾模型具備4種屬性 :1.必備屬性:滿足這個需求,用戶滿意度不會上升,但不滿足這個需求,用戶不滿意會大幅度降低 ;2.期望屬性:提供個性化需求,用戶滿意度會上升,不提供此需求,用戶滿意度會降低; 3.魅力屬性:用戶意想不到的效果,提供此屬性,用戶滿意度大幅提升,不提供也不會降低 ;4.無差異:無論提不提供,用戶滿意度都不會改變,根本不在意;因此在做需求的時候我們應該盡力滿足基本需求和期望需求,而可有可無的需求盡量不去做,降低效率。幸福需求是不容易達到的,如果能滿足是非常棒的~這里就像是滿足了設計心理學的三個層次——本能、行為、反思。

          接下來是大家都熟知的設計手段,適當的講一些述專業的設計技法,用不同的手段去實現的主畫面,最后達到完成設計目標這樣的結果,會讓你顯得更專業。設計的手段有很多種,這里主要講述常用的三種,構圖排版(采用什么構圖方式,為什么這樣構圖是因為什么設計原則)、色彩運用(為什么使用這個顏色,因為這個顏色給人的心里感知是什么樣的)、設計風格(采用什么風格最貼近產品調性,為什么用這個風格),但是講設計時一定要記住產品的調性,不能偏離產品本身,不要盲目套用絢麗的技法,否則是不合適的。

          很多時候面對非專業需求方收稿時,可能看到如下話語———— 

          (心里是不是xxxx····“萬馬奔騰”,用個文明點的詞)

          非專業人士無法理解這二者的區別,他們認為他們的設計手段能達成設計目標,而作為專業設計師的我們就應該引導對方說出設計目標,再用我們專業的手段去滿足對方的目標,去實現減少改稿次數,而不是讓非專業人士去指導專業人士修改設計手段。分清這兩者的區別,我們就可以在設計引導中更加主動。用設計分析的方法來講述設計,舉個例子——

          會議管理——會議預約移動端優化,因為這是我們原有產品EKP里面的模塊,PC端和移動端都有,因此用戶可能是群體也可能是個人。所以針對獨立用戶和群體用戶都做一個用戶畫像,得出他們的一些需求結論,然后目前幸福需求是沒有的,純屬個人建議,日后如果有此功能,想必用戶的滿意程度也會大大提升。

          概括一下已完成的整體主要頁面,分析設計目標: 

          頭部屬于流量量較高的區域,采用卡片式設計,將會議內容置于此處,作為頁面信息關鍵層,采用左對齊方式排版,突出會議標題和時間提醒用戶。

          通過不同的顏色標簽,區分參會人員狀態—— 

          待進行未有操作反饋,選用橙色,屬于可以持續進行并有明顯提醒作用 

          已做反饋屬于成功操作,選用已有用戶認知心理的綠色 

          已知信息拒絕參與,是不太重要的,屬于不再進行的階段,選用灰色

            

          接下來是設計作品的產出過程,一般情況下不可見的過程,為什么要去講,  因為一個東西從無到有是很不容易的一件事,如果能講述過程,就可以引燃情緒共鳴,讓別人記住,讓自己的設計作品也能有始有終—— 

          設計過程一般分為四個階段:初期階段、中期階段、最終定稿;具體的關鍵詞和描述可以通過以下方式提煉出來,這里就不做詳細說明了。

           

          拿運營宣傳來舉個例子,我們公司中秋節月餅禮盒包裝主視覺設計——整個過程應該是有一個系統化的說明的,省略為寫字的地方是我們可以插入的具體圖片和過程,步驟差不多就是上述這些,可以有最初階段的頭腦風暴-提取關鍵詞-清晰定位到中期階段的團隊合作—風格擬定-精選方案-細節刻畫以及和物料方溝通對接的打樣確定工藝等等過程…再到最后定稿的體驗還原-問題優化…主畫面的誕生是不容易的,強化這種過程參與,讓不被看見的事也能展現。如果實在不好記錄,你可以從一開始就截圖你繪制的過程——

          上圖是用PS截圖,再用時間軸將每一幀動態循壞播放,導出GIF然后截一張不變的底圖合成就可以了。

          最后是數據驗證階段,這個是設計落地的直觀證實,包含主觀認可和客觀數據,具體內容就是通過用戶或者專業的人士反饋給你設計落地的好壞,來判定你做的是否優秀成功。通常這一塊的數據決定你驗證你前面所有的過程,只要按照該流程認真做了,最后效果通常不會太差,如果出現很大的偏差也往往是意料之外的,因該尋求團隊一起解決,不是某一個人的問題。

          根據以上最后我們總結,好的設計就是滿足以下4個方面:好看,好用,好記,能實現。設計師要考慮的維度不僅僅在視覺層面,什么是有產品思維的設計師,就是在執行時候要考慮上下游不同職能的工作內容,如果你的設計不能實現,再好看也是白費功夫的~從產品交互視覺多層面談設計,會讓你的設計包裝顯得不那么單調,系統化的方法總結到此,不足之處多多包含~謝謝你的閱讀!

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          文章來源:站酷   作者:YiVi_eleven

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          做好國際化體驗設計,你應該知道的事

          ui設計分享達人





          章節一:為什么要堅持國際化設計?



          堅持走國際化設計的背景

          出海早已成為中國互聯網公司的不二選擇。相比在國內廝殺,國外有更多的人口/政策/資源紅利。并且因為互聯網的可復制模式,使得成熟的經驗可以快速運用到國外,從而搶占先機。而做好國際化的本質就是【做好每個地區的本地化設計】,想用一套國際化的標準去用在全世界的各個地區取得成功是非常困難的

          那有什么好的方法和理論能夠讓設計提前著落,為業務帶來一線用戶信息和設計價值呢?接下來我將給大家介紹一些實際的方法和案例幫助大家做國際化的設計,讓自己的設計價值有理可依


          *以下內容與公司無關,更多的是基于筆者國際化工作經驗的復盤,如有錯誤,歡迎指正(Salute~)



          寫在前面

          首先我們要知道,一套通用的設計標準很難在多個國家吃的開,從而拿到用戶信任

          我們先來看個案例,這個是日本UBER司機端和日本滴滴司機端對比

          最明顯的區別在于,滴滴國際化在日本業務和Global業務這塊,司機端采用的是移動端(global)+平板端(日本),而UBER則是一套方案解決全球問題,可能有些人會問,一套設計不是成本更低,效率更高么,為什么非要制作兩套。這就要從決策成本的角度去考慮問題,而日本市場相對于滴滴其他地區市場有著完全不同的因素,涉及到了資本,使用場景,市場地位,用戶畫像等多方因素決定,這時的【成本與效率】已經無法排在做與不做的第一位了,接下來我們通過兩張照片來看下日本司機的接駕場景

          通過照片我們是否發現日本司機的畫像其實和全世界其他的出租車司機都不太一樣?是不是明顯發現他們的年紀相對的更大一些?會穿制服佩戴白手套? 那年紀更大是不是意味著司機的視力會相對于中年人有所下降,白手套是否會影響他操作屏幕交互,那針對這么不同用戶群體是否需要單獨設計呢?最終的目標是占領市場的話是否要根據本地情況去服務好當地司機呢?


          那我再來舉兩個例子來看看,我們來看看針對日本本地化做的特殊設計細節在哪些方面?



          案例一:針對司機群體老齡化設計———大屏幕設計:

          日本屬于老齡化國家,司機平均年齡更是在50歲以上,高齡人群的視力相比于青年處于退化階段,因此對于高齡人群來說在駕駛的過程中去讀和操作小屏幕來說是一件非常痛苦的事情,UBER采用的是一套國際化的設計語言并沒有針對日本的市場進行單獨的設計,DiDi在日本則是針對司機群體采用了單獨平板端設計,更大的屏幕降低了司機誤操作可能性的同時,也能將字體放大,盡可能讓司機方便識別



          案例二:針對日本司機人文的設計———語音接單

          “日本服務業發達,體現在服務的細節。出租車司機出于對客戶的尊重,都會戴上白手套。但是在帶著手套的時候,司機很難去點擊屏幕進行操作,而且在行車過程中,觸碰屏幕本來就是不合規的行為。無論是從法律層面還是價值觀層面我們都不鼓勵司機做出這種行為,于是開發了語音接單的功能??紤]到司機群體的年紀特征,我們選用了在日本相對普及又好識別的“了解しました(りょかいしました)”進行快速語音接單,在新版本上線后,司機可以通過屏中屏的方式去學習語音接單功能,只有他完全掌握這個功能才會為他完全展現,如果司機因為自身原因無法很好地說出那句話,我們依舊會為他保留按鈕輸入的方式”------國際化業務中的本地化設計


          (圖片來自于SUXA文章《國際化業務中的本地化設計》-呂誠)




          國際化設計的思維框架

          通過兩個日本的案例我們能明確一個點【國際化實質就是做好每個地區的本地化設計】

          怎么樣讓國際化的設計有法可依,我們先來看懂一個關系框架。做好一個產品實質是服務好每一個場景,那一個場景由哪幾個方面組成,簡單來說是由【業務】+【用戶】組成,這并不難理解,我們作為產品設計師,首先是背靠業務,解決公司的商業訴求,給業務帶來利益的同時給用戶帶來更多的使用價值然后獲得用戶的認可。在這個過程中,我們會將商業訴求和用戶價值進行一個有效的結合,從而滿足雙方,但是還不夠,因為一個場景還依賴客觀的條件,比如時間和空間維度,最終也會影響整體的質量,我們將所有的因素通過包含關系展示出來

          接下來我們往細的方向進行拆解,【業務】根據公司行業,階段的不同以及基礎能力的不同,呈現的點也不盡相同。最核心的點在于當前所屬階段,是1.0階段力求生存下來,還是說2.0和競品之間產生差異化,還是活3.0去打敗競品階段。在不同階段設計師要了解的事情也不同,對于1.0階段來說,更精準的展示出用戶畫像和了解當地的文化與習慣是重中之重。但是到了2.0則應該更加關注產品目標與競品的差異化競爭,通過差異化(殺手級)的功能形態獲取更多的搖擺用戶

          不同的賽道,業務不同,打法也不同。我今天主要想講的就是左右場景的另外一個因子【用戶】。那如何定義一個用戶呢?我們先來列舉些具象的特征:

          【外貌/文化風俗/地域特征/語言等】是一個用戶的畫像的基礎組成,但是光有畫像基礎并不精確,因為每個國家的【法律/政策]同樣會影響用戶的行為。而在當今的互聯網模式下,用戶體驗的提高必須得考慮各地區【硬件的水平以及當地的網絡狀況】,最后就是如何與【本地化的設計團隊進行友好的合作】讓體驗和設計策略能夠更加精準的傳達到真實用戶手里,獲得用戶認可,特別是在20年后,疫情的爆發導致設計師無法到前線進行真實有效的實地探測,那么加強合作以及對齊目標,為業務拿結果將是重中之重,接下來,我將對于每個影響【用戶】的因子進行舉例講解








          章節二:如何快速了解你服務的用戶



          做任何的設計都離不開用戶畫像,而做國際化設計一定也繞不開-霍夫斯泰德文化維度理論

          可能你知道,在給拉美客戶做單的時候他們會要求你的界面顏色亮麗,看起來更加奔放,而在給亞洲客戶做單的時候則會相反,整體看起來更加約束。但是你能清楚的知道背后的原因么?如果不清楚那你的這塊分辨更多是依賴于經驗和他人的總結。那有沒有一套理論能夠很好的去輔助你去分析你的客戶用戶畫像,去支撐你的設計。答案是有的,他就是【霍夫斯泰德文化維度理論】


          霍夫斯泰德文化維度理論(Hofstede's cultural dimensions theory)是荷蘭心理學家吉爾特·霍夫斯泰德提出的用來衡量不同國家文化差異的一個框架。他認為文化是在一個環境下人們共同擁有的心理程序,能將一群人與其他人區分開來。通過研究,他將不同文化間的差異歸納為5個基本的文化價值觀維度


          百科連接:霍夫斯泰德理論詳情 (<-點擊快速查看)

          完全不懂的可以看看上面的鏈接,我們這里跳過部分解釋….通過文化將維度理論我們將文化價值觀劃分成6個維度

          了解完霍夫斯泰德理論以后我們該如何去使用呢?我們先從拉美用戶和日本用戶的差異對比開始

          通過霍夫斯泰德官網查詢我們可得知差距最大的兩個分別是【男性化與女性化(Masculinity versus Femininity)】與【長期取向與短期取向(Long-term versus Short-term)】,差值比例達到了46和44.

          接下來我們來對【差值較大】以及【分值較高】的因素進行解釋和舉例,去理解背后的原因



          男性化與女性化(Masculinity versus Femininity)

          日本是個生性好斗競爭意識強烈的民族。在日本企業中工作狂是他們男性氣質的一種表現;而日本男主外女主內,62%的女性在第一個孩子之后選擇辭職,也是男性氣質的另一表現.

          在日本想要成為一個出租車司機,就要在5年之內不能有任何違規,某些地方還會有特殊的考試,這里面的合格率并不高。并且在通過考試之后再在通過一系列的評分后,才能被評為A級或者AA級別的出租車,雖然這僅僅只是一張小貼紙,但是他也代表著一個出租車司機的榮譽。在這一方面,也體現日本社會的男性氣質的確定性。

          相比較日本,巴西人更會以家庭為中心、以教育為重心、博愛、具有個人風格意識。家庭是關鍵。家庭是巴西人生活的中心,也是其社會的核心價值觀。對于一個家庭而言,家人共同用餐的時間是非常重要的,還有星期天的燒烤活動,能讓更多的遠房親戚和朋友聚會。所以在巴西你很難看到休息日去工作的同事,甚至無法聯系上他們:)



          長期取向與短期取向(Long-term versus Short-term)

          日本人將生命視為一個非常短暫的時刻,所以調查發現日本人普遍相信宿命論,他們鼓勵節儉和現代教育的努力,作為為未來做準備的一種方式。

          巴西相較于日本經濟落后,人民的收入水平普遍不高,很多司機收入僅僅能夠維持一家的支出,很難有結余,在巴西工資會按照周維度支付,以保證一家人的生活開支能夠承擔。

          針對巴西的情況我們做了適合當地政策和環境的本地化服務。錢包1.0的時候我們先是和當地的銀行合作推出了巴西99卡,允許司機隨時提現且提現速度遠遠大于了當地的其他銀行(48小時),那這種優勢在收入較低的司機群體當中就會發揮很大的優勢。在3.0的改版中,我們將錢包打造長了本地生活平臺,我們允許司機通過平臺去完成轉賬/水電費/電話費/還款等行為,原本需要走到線下便利店的服務被我們搬到了線上,更是大大的方便了使用99卡的群體。未來呢,我們將加大加多權益,達到使用場景獨占的目的。通過這些服務為我們給用戶帶來了使用價值,同時我們也給業務帶來了價值,更多的綁卡滲透率為我們后續的推廣和矩陣式的打法提供了導流的入口

          (99與當地銀行合作的線上本地生活功能-99Pay)



          不確定性的規避(Uncertainty Avoidance)

          日本地處自然災害頻發地帶,沒有豐富的自然資源,生存條件不太好,所以日本人有很強的危機意識,學會了為任何不確定的情況做好預防措施,對待事情也希望有明確性

          而巴西雖然處于平原,沒有自然災害,但是因為社會安全因素,整個社會對于社恐事件還是有較強烈的危機意識,所以司機會更加關注接送流程中是否會前往不安全地區,以及乘客的質量

          (日本司機的真實駕駛場景)


          費用收取的正確與否也是服務體驗優秀的表現,日本司機會用計步器進行計價,如果涉及到了其他的費用則會使用單獨的計算器進行精確計算,這么做的原因是為了避免計算錯誤給乘客帶來困擾和爭執,那從這個環節來看,司機為了規避【計算錯誤的可能】而預備了計算器,減少了差體驗的可能


          在巴西,滴滴如果對司機派單如果過遠會或者是危險地區會進行提示,允許司機取消派單。并且根據調研司機群體特別是夜班司機會有隨身攜帶防護性的武器用來自我保護,那么也能很好的說明整個社會對于社恐事件還是有較強烈的危機意識。那么做為設計師,是不是意味著可以把危險地區的派單做的更加醒目,讓司機能夠更快識別,更快決策,而不是為了平臺和用戶利益進行隱藏。是不是可以把安全鏈路透傳做的更強,讓司乘都能更加快捷第一時間選擇自助服務









          章節三:繞不開的硬邊界



          法律法規的約束

          每個國家的發展階段不同,對于隱私重視程度不同,因此針對不同地區的海外市場,作為業務的合作伙伴設計師們需要針對不同的市場配套不同的安全合規方案,這一點格外需要注意,不然會被罰的很慘,通常獲取地理位置/賬號信息保留是每個公司都非要需要的,因此在空投其他國家之前需要了解是否立法關于隱私相關的法律,如果有則需要通過配置化將其他國家上線的隱私條款和設置方式復制過來使用

          LGPD和GPDR風控合規

          簡單來說就是要做到信息安全,保護個體隱私。大家都知道在中國我們的信息被侵犯的體無完膚。其實在國外也是一樣,各種權限,各種信息默認保留和上傳。但是隨著各國的重視,個人隱私也逐漸走向明確的法律保護層面。在拉美有LGPD,在歐洲有GPDR


          GDPR 是(The European General Data Protection Regulation )的縮寫,即通用數據保護條例。是歐盟議會和歐盟理事會在?2016?年?4?月通過,在?2018?年?5?月開始強制實施的規定。

          GDPR 意義在于推動強制執行隱私條例,規定了企業在對用戶的數據收集、存儲、保護和使用時新的標準;另一方面,對于自身的數據,也給予了用戶更大處理權。也就是說在18年生效之后,如果再有歐洲任何公司App不對用戶的數據進行合規處理,擅自收集信息就將會受到嚴懲



          智能硬件的普及度以及新舊

          硬件的普及率以及新舊差異也同樣影響著本地化設計,通過調研和外界公布的數據我們得知,在拉美高端手機的占比遠遠低于發達國家。因此在給發達地區做設計的時候可以考慮更多體驗上的拓展,但是在給發展中國家做設計的時候則需要進行小屏幕最小尺寸的適配,這樣做是為了最好的進行向下兼容,從而保證所有用戶都能夠使用。同樣,如果你在給發展中國家做設計,那么復雜的動效和高清晰解析的大圖最好是不要去做的

          (網上后臺數據展示截圖)



          當地的網絡環境和下載速度及物流環境

          拉美國家,基建水平滯后,網絡下載的速率波動較大,且存在不穩定的情況,以及流量費用的價格差異。因此某些設計手法在較發達國家能帶來體驗但是在發展中國家可能會是災難


          舉個例子,司機端的歷史列表如果存在400條記錄,如果司機有訴求想刷新查看更多的訂單,是一次性下拉刷新展示全部好呢?還是一次性展示50條好呢?還是一次性展示20條呢?


          答案是一次性展示20條是最穩妥的選擇,因為網絡的不穩定性,一次性加載太多數據會導致過長時間,而網絡不穩定極有可能導致下載失敗,并且一次性下載太多數據可能并不符合司機查詢的最初訴求,反而浪費司機的寶貴流量,最終會引擎流量消耗過快引發進線,這里的決策是損失一些用戶的體驗去保障司機的收入,但是在拉美因為手機的性能/網速的穩定且快速/套餐足夠便宜,因此我們可以嘗試使用一次性加載全部的數據,這樣能讓體驗感受更好

          (99信用卡的申請權益展示/激活流程頁面)


          再舉個例子,拉美物流相對沒那么發達,且因為政治/經濟局勢的不穩定性,導致物流包裹存在無法送達的情況,如果收件人不知曉當前的狀態而超出了等待的預期,那么他就會進線詢問。那在這個場景我們有什么更好的辦法?是否可以透傳更多的包裹進度方便收件人查看,再者再將用戶導流到客服自助而非進線?這樣的好處一來體驗的鏈路完善了,讓司機可以找到自助的出口,二是方便我們可以更好的了解哪些地區收到郵寄的折損率最大?從而探索新的業務,發現新的機會點








          章節四:生活習慣和歷史文化遺留帶來的本地化策略



          收入/支出方式占比反映了一個群體的現狀

          聊這個話題前我們先將選擇的范圍進行收縮,聚焦在一個國家的一個群體內去看會比較容易解釋。在巴西司機的收入的往往只能支撐下一周的家庭支出,難有結余。這也導致司機會選擇雙開(同時使用UBER接單或者其他競品)或者進行其他賺錢的方法,如果整個群體都是這樣的情況下,那么司機的忠誠度(這里指的忠誠度不是貶義詞,而是每周的出車時長)必然下降。那樣對于大盤的運力來說便是損失。那有沒有什么辦法幫助司機更好的應對這些問題


          我們該如何思考這個問題,通過馬斯洛的需求理論我們能夠將人的訴求歸為三類,基礎的生存訴求/歸屬感和成就感。那這三種可以再細化成兩類,物質層面的訴求和精神層面的訴求。司機愿意在滴滴平臺跑單是基于了物質層面。那么,我們是不是可以豐富收入以外的獎勵形式,提供活動獎勵或者權益的折扣,又或者嘗試下小額貸款,那這些是不是可以給用戶帶來價值點呢?


          精神層面我們是不是也有發揮的空間,對于補貼,往往是有限的。那如何做到持續長期刺激司機群體?如果一個乘客對于司機進行了表揚和小費的激勵,是不是可以給司機帶來更大的信心去服務好乘客,那我們是不是要加強這方面的透傳。是不是可以給司機提供虛擬獎勵,讓司機存在足夠的擁有感和成就感,讓司機群體也能感受到平臺對他們的看重。如果勛章可以,那等級是不是也是成就之一呢?



          現金與線上支付普及與思考

          不同的國家線上和現金的支付比例大不相同,這里受經濟環境和政治環境影響較大。總的來說習慣了線上支付的習慣后就很難回到現金支付的環境,因為確實更加方便便利。一個國家大量使用現金支付的情況下,往往是互聯網公司能做的發力點和藍海。核心做法是通過核心業務導流到錢包模塊,在與當地的銀行和機構進行合作,增加卡和賬戶的滲透率。然后通過做權益和服務,滿足用戶的生活訴求,從而達到場景獨占。最終將會讓公司的業務矩陣從單核的核心業務到核心業務+本地生活




          文字的適配/i18n翻譯的本地化(不同地區/國家語言精準翻譯,拒絕里語/文字長度折行問題)

          這里我們需要提到一個概念,i18n(其來源是英文單詞 internationalization的首末字符i和n,18為中間的字符數)是“國際化”的簡稱。在資訊領域,國際化(i18n)指讓產品(出版物,軟件,硬件等)無需做大的改變就能夠適應不同的語言和地區的需要。對程序來說,在不修改內部代碼的情況下,能根據不同語言及地區顯示相應的界面。 在全球化的時代,國際化尤為重要,因為產品的潛在用戶可能來自世界的各個角落。通常與i18n相關的還有L10n(“本地化”的簡稱)


          了解完i18n的相關背景以后我們大概可以把他定義成做國際化翻譯的一個中臺,所有的本地化設計在經過研發代碼實現后,都會進過他們去對文案進行翻譯校對,最終變成當地人可以理解的話術落地到界面上,從而進行本地化的空投,但是這里面往往存在一個適配優化的問題。大家知道英文的單詞平均長度要長于漢字,而西語和葡語是英文的1.25倍到1.5倍之間,而俄語的長度更是能達到葡語的1.25倍。那么面對多國空投的適配不僅僅需要i18n進行精準翻譯,還需要把控字符長度,避免折行和省略問題


          我們來看下下面這個例子


          (不嚴謹的快速翻譯,只是為了更方便的展示不同文化下的文字長度)


          不同國家的語言不同,文字也不同,則會存在單詞,句子長度/行高的差異。如果一個產品在初期沒有做好適配的話,到后期替換當地語言的時候極有可能出現文字溢出的問題,這也是為什么在做海外設計的時候最好拿當地的語言進行設計,能初篩出一些細小的問題 ,避免在和翻譯中臺對接的時候因為文案太長提供的空間不足而修改頁面間距和留白的適配問題



          中東國家客戶的產品需要注意適配

          如果你服務中東客戶,務必需要呈現出當地的閱讀排版方式(尊重本地化設計)具體的適配細節這里就不過多說了,網上搜索【RTL適配方法】即可

          (Material Design中的RTL適配)



          縮寫是否合適(日期/業內專屬名詞)- 時間格式/貨幣符號/聯系方式/地址等

          格式也是做國際化中一個非常常見且體現專業度的地方,不同國家的時間展示方式不同,會影響用戶的閱讀,舉個例子“03/08/2019”,如果在A國理解是2019年3月8號,在其他國家復用是會存在理解成2019年8月3號的,更別說我們加上的星期之后的展示方式。這就要求我們在進行開新的國家的時候務必于前線進行更好的溝通,保障閱讀的習慣和當地一致,那貨幣符號/地址等也應該遵守當地的習慣去展示,通常的解法是設計團隊去收集信息并且與前線當地人員進行交流確認,將格式記錄下來,最后與研發根據上線的國家展示不同的格式

          藍藍設計建立了UI設計分享群,每天會分享國內外的一些優秀設計,如果有興趣的話,可以進入一起成長學習,請掃碼藍小助,報下信息,藍小助會請您入群。歡迎您加入噢~~希望得到建議咨詢、商務合作,也請與我們聯系。

          截屏2021-05-13 上午11.41.03.png



          文章來源:站酷   作者:大寶蛋

          分享此文一切功德,皆悉回向給文章原作者及眾讀者.
          免責聲明:藍藍設計尊重原作者,文章的版權歸原作者。如涉及版權問題,請及時與我們取得聯系,我們立即更正或刪除。

          藍藍設計www.syprn.cn )是一家專注而深入的界面設計公司,為期望卓越的國內外企業提供卓越的UI界面設計、BS界面設計 、 cs界面設計 、 ipad界面設計 、 包裝設計 、 圖標定制 、 用戶體驗 、交互設計、 網站建設 、平面設計服務


          日歷

          鏈接

          個人資料

          藍藍設計的小編 http://www.syprn.cn

          存檔

          亚洲va欧美va天堂v国产综合