輸出專業規范的命名，建立有效的設計文件命名系統。
項目之初大家都會建立文件夾系統，用來存放項目資源。這時大家可以運用杜威十進制的命名方式來管理文件命名，方便排序，讓我們的項目文件足夠清晰，在長期的項目管理中養成一種良好的命名習慣。
項目命名規則
下面以 用戶端 V2.1.0_新增直售展位 虛擬項目為例，創建各資源的子文件夾，初步完成文件管理：
00_需求文檔（PRD）
01_交互設計（原型）
02_設計文件（設計）
04_競品分析
05_動效設計
06_應用素材
07_參考資料
08_會議記錄
大家可以根據不同項目的性質和流程進行增刪，選擇最適合自己的項目文件管理方式。
在設計文件中，我們最經常接觸的就是畫板、圖層，少則幾十，多則幾百，我們需要更輕松的命名排序方式來查找我們的目標，保證團隊命名風格統一，清晰的場景命名更便于設計輸出和協作，也可以支持后期測試用例的填寫。
此時的命名目標在于清楚展示頁面的從屬關系，以及流程上的交互關系。
畫板&圖層命名規則
每個畫板和圖層需要根據功能模塊/類型/狀態結合數字來進行命名，方便我們對頁面進行排序。數字可根據項目文件的操作順序和權重的具體情況來取舍。
00首頁
01詳情頁
02購物車
03我的
…
在 Sketch 中我們會經常用到一個批量重命名的工具插件 Rename It，這個工具可以快速批量對畫板、組、圖層進行重命名。文末有一篇震震張關于這個插件的介紹，大家可以學習一下。
畫板和畫布的命名規范，是為了讓每個項目參與者都能快速找到目標，對于設計師而言，可以主動思考頁面之間的關系。
一個應用通常需要導出的切圖包含眾多類型：
對于切圖文件夾，可以通過通用文件、控件歸納等方法進行歸納管理。
對于切圖命名，可以無需考慮自己的英文命名具有普適性，記得命名最初的目標是：便于團隊檢索定位，因為開發人員有自己的命名習慣和命名體系。
切圖命名原則
標準命名原則：模塊_名稱_狀態 ，如導航欄_按鈕_點擊；
全局命名規則：模塊_全局_名稱_狀態，如導航欄_按鈕_全局_點擊（全局使用必須加全局標識）
注意事項
如果產品使用了兩個平臺的獨立設計，需要 iOS 和 Android 兩個手機系統的切圖單獨建兩個文件夾，切圖文件分別導出，便于前端工程師檢索應用。
以上是對設計項目過程中的文件管理及命名規范的一些筆記總結，持續優化~
養成一個好的習慣從現在開始。\（ツ）/
文章來源：優設 作者：木子的小千世界
2020 年未過半，我們就看了許多從前從未見過的人和事，體驗了許多從前從未想過的經歷。幾個月來，「歷史性的」、「百年難遇的」、「前所未有的」、「恐慌性的」、「災難性的」……這些詞兒，如同彈幕一般，不停地出現在我們眼前。短短的幾個月，許多人變了，許多家庭變了，許多事情變了，但生活還在繼續前行。經歷過特殊的時刻，在京東的我們，比以往任何一個時刻都要忙碌，也比以往任何一個時刻更能清晰地認識到：「京東的價值、京東給社會的力量」和「我們的責任」。
我們懷著期望，期待我們每一次的改變，都能給你們帶來更多的能量。
2020 年初夏 618 來了，京東的生日之際，京東 APP9.0 全新升級，希望你們會喜歡～
1. 品牌力升級
5 月 20 日，京東零售集團宣布進行品牌升級，由原來的「多快好省」升級為「不負每一份熱愛」。作為京東集團品牌戰略承接的主陣地——京東 APP，將基于全新的品牌精神，著力于滿足消費者的多元化、個性化的購物需求，持續對其創造更大的價值。用戶在京東不僅僅能享受到好的購物體驗，還能享受到更豐富、更用心的產品和服務。通過對京東 APP 不斷地迭代升級，我們也向社會、向消費者詮釋著京東的每一份用心；京東 APP 也承載著每一個家庭、每一位消費者對美好生活的向往，不負你、我、他（她）的每一份熱愛。
2. 產品力升級
未來的 1-3 年，京東將繼續在低線市場、低滲透品類上提速；通過對新老渠道、新老內容的矩陣開拓和整合，將單純的線上購物，升級為全場景的復合式體驗；通過新玩法的打造，增加用戶的觸點，提升粘性和頻次。為了更好地承接京東戰略與方向，京東 APP 的產品力也亟需升級。
3. 體驗力升級
除了品牌力、產品力升級，每一次全新「京東 APP」的到來，也在為消費者不斷提供更友好的使用體驗力。我們也非常期望能夠借助這次版本升級，對京東 APP 進行既精細、又完整的刻畫和打磨，期待通過京東 APP9.0，與消費者進一步拉近彼此的距離，讓體驗更加細膩、更加靈動，全面升級消費者在京東 APP 的體驗力。
結合京東 APP9.0 的品牌力、產品力、體驗力的升級背景，我們追本溯源，探尋京東自己的脈絡。
設計策略的延續升級
基于京東 APP 的核心目標，圍繞購前、購中、購后三個環節強化用戶內心感知，承接京東的戰略在 APP 內的落地。
京東 APP4.0-5.0 主要圍繞京東品牌對用戶的傳達感知進行輸出，建立京東的品牌形象；京東 APP6.0 后開始加強場景能力，逐步打造可以滿足千人千面的電商設計平臺，直至現在，擴寬至全渠道場景，為用戶提供更全面、更加細分的體驗。
始終圍繞產品策略
設計的迭代和產品思維綁定，始終圍繞產品策略，一起共建用戶的同理心；通過深耕設計解決方案、持續驗證推導，來打造值得用戶信賴的優質購物體驗。
設計將各模塊的功能與價值主張相結合，彼此進行聯動，保障從產品到交互到視覺，到最后的方案落地都能圍繞一個核心目標去服務。
京東 APP 設計始終都是以「產品、業務目標」為核心，圍繞「品牌」「用戶」「認知」三大方向，結合「設計趨勢」來發力；但基于不同的情景、當下 APP 所處的環境，設計改版的側重發力點有較大的差異；一般來說是「用一個版本來解決 1-2 個的重大體驗問題」。
我們結合京東 APP8.0 以來的用戶研究報告、用戶反饋、各關鍵模塊的數據、競品對比，從「品牌」「用戶」「認知」這三大維度著手，梳理京東 APP 的核心體驗問題，進而推導出京東 APP9.0 要解決的核心問題，作為定義京東 APP9.0 設計策略的關鍵依據。
1. 品牌設計 ——京東APP8.0問題提煉
在細分用戶的研究中，用戶高頻地提到 APP 的品牌感知過于冷靜、直接、有距離感，氛圍上不夠活潑，也存在「京東是正品但價格會不會更貴？」的疑惑。打個比方，可能同樣的價格，吆喝聲越大，感受上會覺得大聲的更便宜、更有爽感。
視覺定義上，一方面，柵格定義過于精細，影響了信息傳遞的流暢度，需要針對導購類、流程類場景進行差異化刪減；主流程內的部分模塊留白偏多，拉低了一定的屏效；另一方面，字體的部分梯度比較多、也比較相近，雖然視覺上較為協調和統一，但視覺噪音較大，對主體內容也有比較大的干擾。
人機交互時，過于直接地強調目的性，品牌靈動感待提升。
通過數據測試發現，核心模塊的引流效率還有較大的提升空間；兩個例子：1、可通過「嚴格控制變量，測試圖片素材的引流效率」，提升「圖片素材」的質量，優化核心模塊的設計規范；2、通過「圖片素材」的質量提升，加上對「坑位容器」動態打磨，經過數據測試，增強品牌靈動感的同時，可進一步提升屏效。
2. 用戶感受 ——京東APP8.0問題提煉
細分垂直的用戶群，在全流程內的感受上存在割裂感；各個垂直人群在 APP 主流程內已初步形成大的體驗閉環框架，但體驗閉環的細節還有待補齊與提升，對垂直人群的「權益和身份」的傳達還需要在情境上更加一致。舉個例子：未開通 PLUS 會員時，高凈值人群對 PLUS 身份認同感還有較大提升空間。
商品的活動促銷信息展示（時間、最優價格）層級隱藏較深、活動促銷計算復雜難以理解，用戶促銷感受比較弱，所謂酒香真是怕巷子深。我們通過「用戶在不同平臺內促銷感知」的用戶測試對比發現，雖然京東的價格最優惠，但由于在表現層上沒有進行強調，導致用戶在價格感受上存在偏差。
產品感知較理性，主流程內氛圍不夠活潑，有距離感；這一點，新興市場用戶的感知尤為明顯。
3. 認知統一 ——京東APP8.0問題提煉
頁面框架一致性問題：主流程過往的版本較為側重于單一模塊內的設計，各個模塊間堆積了較多設計不統一的問題。
頁面內模塊一致性問題：主流程的各個模塊內，由于 「新舊版本」「需求不斷疊加」等原因，也存在模塊內的統一性問題，這增加了用戶接受信息的負擔。舉個例子：APP 結算頁在過去的一年內新增了較多的功能與提示場景，由于業務時間有 deadline，很多需求會采用體驗降級方案，即用現有控件來設計方案，使得最終方案可能體驗不夠好，而這里埋下的體驗隱患，日后依然要找機會解決。
業務和功能類型不斷增加，這會導致頁面相對臃腫，這時核心流程的框架亟需重新定義、向三維空間借力來舒展信息架構。
APP 整體的故事性連接還有待強化，貨架式的流轉只是骨架；各頻道內、各模塊內也應基于 APP 骨架保有自己橫向與縱向故事線，在 APP 內注入故事性的血肉靈魂；讓用戶在 APP 內流轉時，認知更清晰、體驗更豐富。
1. 品牌力設計策略
延續、強化京東品牌，構建、升級「京東設計語言體系」 ，提升屏效。通過統一的強調，使品牌可知；通過情感化、IP 化、故事化的表達，使品牌可感。
色彩體系：延續京東品牌調性，主打京東紅的品牌色，適當地通過增強配色、減少留白，在保留京東辨識度的同時，通過豐富的色彩體系降低 「冷淡、有距離」的感知。
例如：結合首頁及推薦位的坑位顏色，拉通營銷色彩規范，HSB 平衡所有色彩梯度；并結合算法給出冷暖色排布規則，區分內容豐富畫面（包括首頁核心樓層/我京工具與服務/用戶資產我的錢包）及核心流程 HSB 平衡，色環關系，品牌色的延伸主導，再到單色、漸變的規律體驗，全路徑的感知；拉通京東品牌色同階梯色環，推導所有輔助色色值，根據透明度及飽和度疊加，得到色彩使用場景及漸變關系；提煉營銷體系核心規律，營銷坑位色彩排布關系，冷暖色階搭配，引導用戶識別。
營銷坑位色彩排布關系，冷暖色階搭配，引導用戶識別。（核心樓層為例）
字體體系：延續京東的字體建設，延續性的使用京東朗正和正黑體、加大主字號、精簡字階，拉開字體層級梯度，讓用戶的關注點更聚焦。針對下沉首頁等重點業務采用異形字體，標題與利益點字號字重比重更大，強化營銷引導。
icon 體系：線性圖標全面 iconfont 化，減少 app 的體積；圖標設計更簡潔，減少隱喻的手法，讓用戶「一眼即懂」；平衡視覺的體積差，建立一致性的圖標繪制尺寸規范；適當的設計圖標互動的微動效，增加趣味性，帶給用戶「愉悅感」。
柵格體系：在屏效留用率上，基于 8.0 基礎定義擴展 12 、24 的倍數關系，柵格做相應的簡化；比如在首頁/搜索/商詳等頁面，利用刪格縮減間距，提高單屏屏效；首頁核心樓層，利用減少間距，放大商品圖片，壓縮整體樓層高度，使核心內容更加突出，更便于用戶識別到有效內容；
優化界面布局，巧用視覺動線，利用人們閱讀的 f 型習慣，聚焦用戶閱讀內容；
素材設計體系：一方面，打磨坑位容器，采用動靜態容器相結合的手法。另一方面，打磨坑位素材規范，動靜態素材結合使用。同時，嘗試壓縮容器高度，與羚瓏智能設計系統深度合作，進行素材和頁面的測試，對運營設計的素材規范進行打磨，在容器高度壓縮的同時提升素材質量，保證瀏覽效率不下降。
2. 用戶設計策略
細分用戶群體，增強氛圍感知、讓體驗更豐富，層次更清晰。根據細分用戶的習慣性、常識性認知，適當地把產品進行分層，讓可知可感更加貼合用戶；基于全局的統一，有意識細分用戶的體驗，加強各垂類用戶最在意、最可感受的局部差異，從而讓體驗更加豐富。
PLUS 會員：提高 PLUS 會員身份認同，通過全流程內 PLUS 會員皮膚、氛圍品牌一致性露出， 強化「PLUS 專屬優惠價格計算」 「PLUS 到手價強化」等權益的感知，進而強化會員身份的感知、加強對 PLUS 會員的認同感。
家庭銀發人群：渲染家庭情感氛圍，強化優惠及促銷的利益感知，簡化整體的使用流程，中心化界面采用大字號，為銀發人群設計。
新人用戶：打造新人專屬首頁，強化新用戶引導，多流程定投新人大禮包、發放新人專屬優惠，全方位助力新人用戶轉化。
校園用戶：著重打造年輕化的視覺氛圍，拉近與校園用戶的距離。
新興市場用戶：扭轉用戶品牌認知，基于特定人群偏好的氛圍組織界面，提升流量分發效率。針對促銷較為敏感的人群，通過設計的強調，加強用戶低價感知，強化活動促銷感知，打消購買顧慮。
3. 認知設計策略
品牌金字塔理論認為關于品牌認知的一系列表象指標，如認知度、美譽度、購買率、滿意度、推薦率等，實際上反映了消費者對一個品牌認知的深入程度；這個理論，同樣可以適用在產品的用戶認知上，認知是一切的基礎，產品的用戶認知做好了，轉化、推薦、滿意度才能做好，能夠被認知的產品更容易加強情感連接；反過來，不容易被用戶認知、認知有負擔、信息架構表現層復雜的產品，用戶理解起來可能就有障礙，再疊加情感連接的設計，那有可能就是體驗的自嗨了。
京東 APP9.0，將針對用戶的主流程，骨骼精細化重構、優化流程動線，給用戶提供一致性的體驗，讓認知減負。
4. 感受設計策略
消費者在只有認知的時候是理性的，而基于認知產生好感的時候就會變成感性。
在簡化用戶的信息認知的基礎上，我們將強化打造「京東語言的品牌動效」在核心流程內的模塊感知，結合產品的產品領域動態銜接的訴求，在設計上考慮動態效果對「整體上下文，故事連接性」的亮點承接，讓用戶理性購物的同時，感受到感性的愉悅。
1. 用心設計每一眼感受
設計策略：延續、強化京東品牌，完善并深入刻畫京東設計語言；通過設計的語言體系，提升屏幕效率，從而帶動流量分發效率、運營效率的提升。
首頁視覺風格煥然一新，更靈動、更輕松。（通過 IP 和品牌輔形融入、優化色彩體系等方式，強化京東品牌；通過優化柵格系統、字體系統、色彩體系、動態效果，讓界面的信息更加清晰，界面感受更靈動）
2. 用心對待每一個群體
設計策略：細分用戶群體，增強氛圍感知，讓體驗更豐富、層次更清晰。
設計要點：打造家庭專屬購物體驗，和家人一起在京東開心購物與互動。設計上通過暖色調和插畫的鋪陳，渲染家庭情感氛圍；同時，界面采用更大字號，為父母量身定制。
設計要點：打造 PLUS 會員中心化與去中心化的購物體驗鏈路；通過設計走查與用戶測試，填補 PLUS 會員在全流程內的品牌、信息觸點缺失；同時，從品牌、視覺、交互三個維度，統一設計語言、語境、對話方式，讓 PLUS 會員在各個體驗觸點都能感受到一致的人機交互體驗。
3. 用心打造每一個場景
設計策略：基于京東設計語言體系，構建場景；骨骼精細化重構主流程，構建「場景動線」，讓體驗更流暢。
設計要點：京東到家、便利店、商超、藥品、鮮花等門店商品全面入駐京東 APP；用戶在主流程內即可以直接搜索下單附近的門店商品，下單后最快 15 分鐘內便可送達；由于到家場景依托于主流程，我們在設計時期望用戶購物動線能與主流程統一，在商品池打通的基礎上，體驗上也能完美融合；同時，設計上需結合 LBS 場景特點，在主購物流程中，強化 LBS 與商品、配送的關聯，突出商品促銷與門店配送時效。
4. 用心打造每一條動線-多元化導購
設計策略：基于「京東視覺語言體系」，細分用戶群體構建導購方式；根據用戶特性，強化放大「多元」的體驗。
設計要點：直播全面滲透，全流程強化直播觸點，增大直播的分發場景的用戶接觸面積；同時，通過動態強化、設計強化的手法，加大對商家私域直播的引導，完善直播場景的體驗。
5. 用心打造每一條動線-購物動線優化
設計策略：基于「京東視覺語言體系」骨骼精細化重構購物動線，統一交互、視覺語言，視覺降噪，讓認知減負。
6. 用心簡化每一次決策
設計策略：關鍵信息強曝光，統一交互視覺體驗；讓認知減負，決策更簡單。
大促氛圍優化：在主流程內突出大促的氛圍感知，強化搜索列表、商詳等主流程內的大促氛圍；結合大促情緒指數設計氛圍，逐漸調動用戶的熱情。根據用戶的身份、商品的特性，在設計上突出重要信息，例如強化 PLUS 會員促銷腰帶等；同時，借助設計規范和設計組件，頁面內彈層更加容易拓展、可自由配置。
到手價場景展示：商品詳情、購物車內強調商品到手價，在設計上突出優惠結果的傳達，讓用戶一眼便知。
7. 用心滿足每一次閑暇
融入品牌、IP 元素，用心打造新穎、有趣、持續的互動玩法。
8. APP9.0
京東 APP9.0 是一個新開始；我們將用未來的時間，用心跟大家詮釋，京東全新的品牌價值主張「不負每一份熱愛」。用心對待、不負期待、不負熱愛，我們在路上……由于篇幅有限，本文就不展開分析詳細的設計方案了。
文章來源：優設 作者：京東設計中心JDC
一年一度畢業季來襲高校畢業展海報簡直「神仙打架」
大家好，我是美丫姐，今年，因為疫情原因，各大高校畢業生可以說是哭笑不得，先是因為人聚不齊，拍個畢業照都拍不成，只能上手 p。
再是各高校想方設法也要讓畢業生有個難忘的畢業典禮，紛紛搞了一出「賽博朋克」撥穗儀式。
這得虧是大白天，要是晚上在校園撞到這玩意兒還不得給人嚇個半死！
不禁讓網友紛紛大呼「搞點陽間的東西吧！」
但即便是這樣，也絲毫沒有減少，藝術院校辦畢業展的熱情全國各地各大藝術院校，都紛紛舉辦起了線上畢業設計展，斬斷大家想逃過做畢設的念頭，畢業設計展照常舉辦，那么畢業設計展宣傳海報也一定少不了。
接下來，就讓美丫姐帶著大家來品品，今年各大藝術院校令人「眼花繚亂」的海報。
廣美以其縮寫 GAFA 組成的動態 3D 圖形利用視差讓人產生錯覺，頗有幾分韻味。
就是搭配上富有節奏的 BGM 后，讓人不禁想到那句傳唱大街小巷的廣告詞「一年逛兩次海瀾之家，每次都有新感覺」。
你看，這亦實亦虛的透明物體像不像甲方虛無縹緲的需求……
彼時，這一疊疊的紙張是一次次熬夜趕的作業此時畢業了，這一疊疊紙張將會是你被打回重做的稿子
去年被全網吐槽的天津美院海報，天美 2019 年畢業展海報
今年選擇打一張規規矩矩的保守牌
不管甲方有多奇葩但畢竟給了錢，不管有多少坎坷都得咬著牙勇往直前 ，逆流而上！
這向四面八方發散的線條就像甲方天馬行空的想法，沒有重點，也似乎沒有終點。
稀疏的黑白線條，就像學設計后你的頭發，做設計，做到最后白了少年發，又禿了頭。
這需要瞪大眼看的 PPT 式動態海報，不正代表著更新迭代快速的時尚圈嘛！
畢業，能帶走的是屬于大學 4 年的回憶，難以帶走的，是積攢 4 年的行李，一看這陣仗，快遞費肯定不便宜。
中間的圓就像催眠師搖擺的鐘表，這畢設，是越做越瞌睡……
兩耳不聞窗外事，一心只往屏幕鉆，這才是一個優秀設計師的優良品質。
設計師：「你好，有什么需要我服務的嗎？」
甲方：「需要做一個 logo，目前預算 20」
設計師：「好的，再見」
俗話說得好，做設計不帶參考線，都展現不出設計師有多用心。這不，理工學院密密麻麻的參考線，哪個甲方拿到手不會覺得物超所值。
只是輔助線過于密集我看了三遍才看出寫的啥。
甲方的心就像一個無底黑洞，你永遠不知道他在想啥，他給你的意見也總是在你意料之外。
做設計師，不僅要會動手，還得眼觀六路，耳聽八方能說會道，還要會「嗅」出空氣中的氛圍，這才能把甲方爸爸服侍得妥妥帖帖。
每個看向不同方向的眼珠，就像一個項目有好幾個甲方，每個甲方都有自己的想法。
藝術，總是得留有一絲絲神秘感才能吸引大家的眼球，就像馬賽克后內容總是令人好奇。
除了大陸各大高校畢業展海報外，臺灣的畢業展海報也是百花齊放。
作品記得署名，被盜了你都沒地兒哭去。
水印打得再滿也不如自個兒的臉辨識度高，實際上畢業作品是個 AR 濾鏡。
設計就是一場探索，多走幾次，就能摸清楚甲方的套路。
選專業前猶豫做什么設計，設計系畢業后：「做什么設計！」
遇到蠻不講理的甲方，多深呼吸幾次忍忍也就過去了。
保持一個樂觀的心態，才能發現設計的世界多姿多彩。
你看這從上到下密密麻麻的人海，就像是一次次嘗試夠到甲方需求，卻又一次次失敗的你。
看這畢設把孩子逼得這醫院看來沒少去。
無論何時，回憶起肝畢設的日子，就連軟件頁面都能浮現在眼前。
當你正式成為設計師你會發現，做多了辣眼睛的設計，你的眼球將會變成消耗品。
縱觀今天所有的畢業展的海報設計，有的難以理解，有的讓人出乎意料，但唯一可以肯定的是，無論條件多糟糕，哪怕不能像往年，有展館可給學子們呈現自己的創意，熱愛設計的大家，創作的熱情，也沒有被這場突如其來的疫情澆滅。
雖說有些海報可能不能做到，讓所有人滿意，但校方也盡力，為同學們搭建了一個可以展現，大學四年學習成果的舞臺。
文章來源：優設 作者：你丫才美工
通常產品經理在立項前都要思考需求的實現方式：是原生做？還是 H5 做？
問題的答案會因實際情況有所不同，如果追求體驗，那原生效果更好，如果追求短頻快，那就選用 H5，或是兩者結合。
CCtalk 是個涉及 7 大端的跨平臺產品：iOS、Android、PC、Mac、Web、觸屏、小程序。我們在日常項目中（尤其是用戶增長類的項目）越來越多選擇用 H5 實現，然后以低成本適配方式應用到不同客戶端。
這樣做的好處在于：
降低了開發成本。原本要涉及 iOS、Android、PC（PC 和 Mac 用同一套 Qt 實現）、H5 這 4 個端的開發人員，現在采用內嵌頁的方式，可以做到完全不涉及移動端和桌面端，或者僅是入口放置這類比較簡單的工作。
降低了維護成本。如果有優化調整，可以只改 H5 頁面，不用各個端都動手。
好處顯而易見，當然這也不是件一本萬利的事?？聪旅孢@張 App 和 PC 屏幕尺寸的對比圖就明白了，長寬比差異這么大，頁面在適配的時候，有時需要優化調整布局。
△ App和PC屏幕尺寸對比
如果要真正做到流暢順滑的體驗，流式布局是最佳選擇，但是對設計和開發的要求都很高，維護成本也不小，這讓大多數團隊望而卻步。所以還是自動適配寬度、媒體查詢（斷點適配）等相對低成本的方式比較香。
如何以低成本的方式做適配？這個問題涉及 2 個方面：框架和頁面。
△ 框架和頁面
先來看看框架，大致有 4 種：觸屏、App、PC、Web。通常一個項目會涉及其中的幾種，也有少數情況都涉及。（此文暫不討論小程序，有機會再寫一篇關于小程序設計的文章）
1. App
CCtalk 用的 App 框架容器是公司橫向團隊提供的 Web View，有 2 種：
常規的導航樣式。元素包括：返回、頁面標題、分享（根據需要選擇展示或不展示）。安卓和 iOS 略有區別，iOS 為了導航欄的順滑過渡效果，用的是同一個 Web View，所以無法滿足在一系列頁面中部分頁面有分享按鈕，部分頁面沒有分享按鈕。安卓用的不是同一個 Web View，所以沒有這個問題。（此處不展開討論）
透明頭部導航。常規導航無法滿足一些個性化的設計需求，所以透明頭部導航就應運而生了?？梢詫Ш綑谶M行自定義設計，營造沉浸式的體驗。
△ 2種頭部
2. PC客戶端
PC 客戶端的框架導航包括：返回上一頁，返回首頁。頁面內嵌時，要留意容器導航和頁面導航是否有重復或遺漏。假如要保留頁面導航欄，那需隱藏返回按鈕；如果去掉頁面導航欄，則需將導航欄上原有的操作（例如分享）通過懸浮等方式保留。
△ PC端的全局導航
一般的設計流程是：先設計觸屏頁面，再去看看 PC、Web 頁面是否需要調整。
響應的總原則：提高屏幕利用率。
具體評估標準有 3 點：
頁面元素從小到大可分為：控件→組件→模塊→頁面，按照不同維度的復用，并結合自身的項目經驗，整理出 3 種常見的方法（此處是重點，看我看我）。歡迎小伙伴一起討論補充。
△ 3種常見的適配方法
這種方法最簡單，幾乎不用動腦子。具體實施方式又分兩種：
案例1-拉到指定寬度：
像帖子這類結構簡單的內容頁一般都可以直接拉伸。注意檢查是否有遺漏操作，一般在 PC 端可以采用懸浮按鈕的方案將移動端的操作保留。
△ 帖子頁
案例2-居中顯示，兩邊留白：
如果頁面直接拉伸給用戶增加了操作成本，可以采用將主體內容居中，頁面兩邊留白的方式。
實名認證項目是將同一套實名認證流程復用到 3 個不同的使用場景中，所以頁面需要適配觸屏、web、PC 彈窗 3 個框架尺寸。如果將觸屏頁直接在 Web 上拉伸，那不僅樣式上不美觀，而且右側的「修改」、「獲取驗證碼」等操作按鈕距離左側的標題太遠，根據格式塔的接近原理，右側的一列藍色操作反而會被誤以為是一個整體，脫離和主體的關系，不易于操作。所以我們的做法是放棄拉伸，而是將主體內容居中顯示，頁面兩邊留白。
△ 實名認證頁
這種方式雖然簡單，但也要注意可能會涉及一些細節調整：
如果所有頁面都能這么輕松適用于各個不同端，那對設計和開發來說真是省心省力，皆大歡喜。然而現實不會這么順風順水，有些頁面放到不同的框架內會「水土不服」，這時就需要設計師出馬做些調整。
這種調整適用于有圖片和列表的頁面。從設計層面改動不算大，而且開發量適中，開發也比較能接受。
案例1-排行榜
在課程排行榜項目中，有一個榜單列表頁，展示榜單的具體排名和獎勵等信息。
如果直接把觸屏頁面搬到 PC 端，滿眼是大寫的「丑」，從設計角度分析，用戶的閱讀負擔和操作負擔也過重，屏幕利用率低，鼠標滾了半天也沒看完一半榜單。
△ 直接拉伸——丑&不好用
所以這個頁面需要設計師改造一下才能適配到 PC 端，具體怎么做呢？
我們來分析一下它的頁面框架和模塊。頁面從上到下分為：獎勵 Banner、tab 區、列表區和我的排名 4 部分，結構相對來說比較簡單，在 PC 端可以保持大的框架結構不變。
△ 頁面結構
因為移動端是以縱向為主的屏幕，而 PC 端是寬屏，需要進行調整的模塊分別是：獎勵 banner區（圖片類），其他名次列表（列表類）。對于圖片適配，在這個項目中可以采用不同端使用不同比例圖片的方案。對于列表適配，在 PC 端由 1 列調整為 2 列，以提升閱讀效率。
△ 保持頁面框架，調整圖片和列表模塊樣式
案例2-課程售賣頁
圖片的適配處理，除了采用不同比例的多套圖之外，還有另一種方式——保持圖片比例不變，調整頁面布局。將圖片和標題從上下結構改成左右結構。
△ 課程售賣頁
小結：
保持頁面框架，調整模塊內樣式的方法適用于結構相對簡單，有圖片和列表等特殊元素的頁面。
對于圖片適配，有 2 條思路：
如果頁面模塊多、結構復雜，靠小改還是會造成閱讀障礙和操作負荷，那就要用方法三——模塊級復用，重組頁面布局。
案例-課時學習頁
課時學習頁是個多模塊的復雜頁面，分別有視頻播放區、課時基本信息、目錄、網師、評價和推薦。整體思路是將頁面結構由 1 列調整為左右 2 列，以此來提高屏幕的利用率。
模塊的具體位置根據其重要性以及和內容主體的相關度來排布，例如目錄：從平臺角度希望用內容吸引用戶，增加觀看時長；從用戶角度是需要經常點擊切換的，對于這種重要性高又操作頻繁的模塊，當然應該放在第一屏內。例如推薦：和內容主體的關聯度不高，所以優先級低，放在右側較小的區域內。
△ 課時學習頁
在復用模塊時，要注意是否有手勢操作的場景。如果觸屏端有左右滑動的模塊，在 PC 端適配有 2 種做法供參考：
另外，要注意浮層的特殊處理。手機端一般通過浮層展示更多信息，在 PC 端適配時，需將浮層調整為固定模塊。例如移動端吸底的課程介紹浮層，在 PC 端改成固定在目錄下方。
△ 浮層的適配
以上是我結合項目經驗總結的 3 種低成本頁面適配方法。當然，在具體的適配中還會遇到許多細節問題，需要 case by case 去處理。
文章來源：優設 作者：魚游設計
你的設計是否能被理解？為什么設計的價值總是不被人認可？本文將從深入淺出，帶你了解全局性設計思維的真正力量。
你的設計是否能被理解？為什么設計的價值總是不被人認可？
設計不僅僅只是帶來美感，好的設計能夠為產品、公司甚至整個社會創造巨大的價值。而在創造好的設計這個過程中，最重要、也是最容易被人忽視的，便是設計思維。
何為全局性設計思維？它能夠為設計師帶來哪些價值？本文將從設計的本質出發，結合設計的發展趨勢，帶你了解全局性設計思維的真正力量。
目錄
這篇文章的主要內容，來自我在 19 年底的一個沙龍分享。整個分享以設計思維的角度入手，講述了全局性設計思維的來源和重要性，以及我是如何在不同產品線上去運用這種設計思維的。
何為全局性設計思維？為什么要講這種思維方式？
這是我一直在探索并實踐的一種設計思維。從最開始的理論雛形，到各種項目的實踐，不斷進行修正和完善，最終形成了一套卓有成效的思維方式。通過這種思維方式，我逐步幫助產品解決了許多長期性的問題，并最終構建了各種不同類型的設計體系。最終，隨著品牌矩陣與產品體系的落地，形成了一個完整的網易智慧企業設計體系。
△網易智慧企業設計體系
因為篇幅原因，本篇文章將重點從理論層面闡釋全局性設計思維的導論、價值及使用方式。而具體的實戰案例，我之后將會以另外幾篇單獨文章的形式進行展現，并詳細講解在設計過程中的一些細節與過程。希望能夠幫助大家更深入地去理解如何根據不同的場景正確地去使用這種思維方式。
未來可能會包含以下幾篇文章：
當然，目前的設計體系僅僅只是一個開始，未來還有很長的路要走。
希望本文能夠為你帶來小小的啟發，讓設計思維幫助你更好地發揮設計的價值。如果你對某一方面特別感興趣，可以直接跳到這一章進行閱讀，無需浪費過多時間。如果你有任何疑問，也歡迎隨時與我交流。
這次把序放在了第二段，這樣子看上去就不那么不務正業了哈哈。當然，寫序更多的是為了記錄生活，希望每一篇文章不僅僅只是傳遞知識，更是一篇有溫度的文章。
整個 2019 年中，經歷了很多事情，人生觀也隨之發生了些許變化。
從并肩作戰的同事的不斷離去，到逐漸需要考慮團隊的發展。從單打獨斗闖天下，到思考如何讓整個團隊更加優秀、如何建立完善的設計體系等等。
角色、心態、責任，以及如何坦然地面對自己。
活在當下，用心生活。這是我一直當作座右銘的語錄，也是我希望給自己的承諾。總是試圖去嘗試這種狀態，但卻異常艱難。像我這樣的人，看上去總是「積極向上」，總是「規劃未來」，總是希望事事完美，強迫著每個細節的完善。但不知不覺中，人生好像開始進入了「自動駕駛」的模式，活在了過去的思索中，活在了未來的規劃中，唯獨對于當下異常麻木。
這并不是我想要的生活，我開始嘗試做出改變。
偶然間，通過一些書籍，我開始嘗試正念禪修。感受每個呼吸中空氣的流動、感受身體的每個部分、感受當下空間發生的每一件事情。雖然只是很淺顯的境界，但正念依然對我產生了巨大的影響。我開始重新地審視自己的人生，審視自己的生活狀態。
△ 網易蝸牛圖書館：與快樂的小伙伴們
這種感覺，就像再次的呼吸了新鮮空氣一樣。
我們其實只存在于當下的時空中，過去和未來，并非真實存在的事物?；叵胍幌?，我們有多久沒有像小時候一樣，完完全全、毫無雜念地享受在當下的時光中了？
用心活在當下，平靜地接納一切發生的事物，這種感覺真是太美好了～
對于設計師來說，什么能力更為重要？是設計這門「技術」本身，還是思考如何去設計的「思維」能力？
對于不同的設計師來說，一定會有不同的答案。
這兩種能力本身并不矛盾，他們相互影響，互相促進——就像「術」與「道」之間的關系。設計能力決定了設計作品的輸出質量，而設計思維則決定了你思考問題、解決問題的能力。
然而，在現實的大環境下，「術」的重視程度遠高于「道」，造成了很多設計師與日常業務的「分離感」。以至于，多數的設計師，無法將自己的設計能力有效地用于日常業務中；抱怨他人不理解設計，也因此錯失了許多機會。
重視設計美感，其實并沒有問題。視覺是最直接的表現方式，我們從最初開始喜歡這個行業，并最終成為設計師，大概都是因為如此。包括我個人，也是美感的追求者，常常為了幾像素的細節，調整無數稿。也常常沉浸于自己的作品無法自拔。
但是，美感之后，設計還需要什么？
路易斯·沙利文曾講過：「形式追隨功能」。而功能存在的意義，則在于解決問題。視覺的形式、美感，很多時候只是包裹在外側的表層，而解決問題才是設計真正的核心。視覺的表現，一定要遵循解決問題的方式，向用戶傳遞恰當的信息，最終引導用戶以此來解決問題。
因此，我更希望更多的設計師，在追求美感的同時，能夠重拾設計思維本身，尋找設計最根本的價值。
我們其實可以站得更遠一些。學會去理解事物，學會用設計去解決問題。再以此為基礎，通過你的設計能力去塑造它、點亮它，讓它成為一個真正美好而又有價值的設計。
而設計的價值，將會成為你的價值。
互聯網時代中的數字產品設計，需要什么樣的設計思維？或者說，當下我們需要什么樣的設計思維？
這個問題的答案，好像一直在變。
互聯網本身便是一個新的形態，1989 年「萬維網」發明，1996 年中國引入互聯網，到今年已經有大約 24 個年頭。我們經歷了不同的互聯網時期，而「設計」的概念也一直在變化中。
Internet 1.0 PC 互聯網時代。在這個時代，我們將大量的信息虛擬化，并通過網絡進行信息傳遞。而我們的「設計師」們大多被稱為「美工」，我們的「設計思維」，便是將信息變得更好看。
Internet 2.0 移動互聯網時代，或者稱為消費互聯網時代。自從 2007 年喬布斯發布第一代 iPhone 之后，疊加 4G、wifi 等技術，手機成為日益重要的終端，世界逐漸進入了移動互聯網時代。伴隨著 iPhone 與其應用的出現，喬布斯讓所有人理解了「用戶體驗」的重要性。我們不再是「美工」，我們變成了「UI 設計師」、「交互設計師」。而這個時代，我們的設計思維變成了「用戶體驗思維」。
那么，下一個時代在哪里？我們的設計思維又將如何轉變，才能適應下一個時代？
1. 紅利消失、增長觸頂，互聯網下半場到來
最近幾年，我們已經能夠明顯地感知到——互聯網的「寒冬」真的來了。隨之而來的，便是互聯網的發展方向似乎也正在發生變化。于是大約從 2017 年開始，互聯網圈內逐漸出現一個新的名詞——互聯網「下半場」。人們普遍認為，中國的互聯網將會由消費互聯網時代進入下一個時代，即互聯網下半場。
我并不完全認同互聯網「下半場」的稱呼。互聯網本身是一個年輕的行業，中國互聯網「下半場」，其實更像是互聯網發展方向轉變的標志。
因此，我們認為的下一個時代的方向，也許將會是 Internet 3.0——即產業互聯網時代。
互聯網為什么必須要進入下一個時代？
對于互聯網企業來說，一方面在成本端，隨著人口紅利消退，勞動力價格上升，企業的成本將逐漸升高，倒逼管理者使用系統和工具來提率；另一方面，在收入端，野蠻增長的時代結束，增量經濟轉向存量經濟，紅利經濟轉向效率經濟。
在「成本」與「效率」的雙重壓力下，再加上整個市場經濟的下行周期，整體經濟出現下滑，而一些依靠融資的互聯網公司將難以為繼。因此企業不得不尋找方法來提升效率，降低成本——而這正是企業級軟件（ToB 產品）最擅長的地方。
因此，在互聯網寒冬之下，ToB 市場便理所應當地開始被重視。
讓我們縱觀整個中國市場的發展，互聯網的興起雖然促進了消費領域的蓬勃發展，但產業領域的發展則因此受到了巨大制約。中國率先從消費端、從第三產業開始數字化，然而在第一、二產業的數字化進程似乎并不是很快。一個重要的原因是，人口紅利促使了消費互聯網的快速發展，而這種紅利讓人們忽視了產業互聯網的重要性。
在寒冬之下，我們終于發現，消費互聯網蓬勃的基石，正是底層堅實的產業互聯網。產業互聯網如果不能得到有效的發展，則整個市場經濟將無法更進一步地發展。
因此，產業互聯網時代的到來，是中國互聯網發展的需要，也將是大勢所趨。
2. ToB市場將迎來機遇
產業互聯網的發展，需要依托 B 端領域的發展，并逐步融入并帶動整個產業進入互聯網時代。那么，B 端產品在中國目前處于一個什么階段呢？
對于整個中國的 ToB 行業發展現狀，大多數的人并沒有一個清晰的概念。盤點中美上市的科技公司會發現，美國 toC 領域與 toB 領域市值之比是 6:4，但在中國這個數字是 20:1。
雖然互聯網的整體環境不同，但中國 ToB 行業的發展，顯然是落后太多了。于是乎，2018 年開始，BAT 大舉布局，PE、VC 加速進場——中國 B 端產品已經逐漸進入必須發展的時候了。
中國市場已經坐擁全球最發達的消費互聯網體系，而產業互聯網的發展卻嚴重滯后。
同時，對比 B 端中云計算領域的 IaaS、PaaS、SaaS 三層架構，全球市場中 SaaS 占據了 52.5% 的份額，在中國卻是 IaaS 分走了最大的蛋糕，占比達 61.2%。中國市場 VC 的投資總額已經與美國相當，在 SaaS 領域美國企業獲得了全球 70.1% 的融資，而中國只有 11.7%。
因此，在互聯網下半場，相對于 ToC 行業的觸頂，ToB 行業將會迎來歷史級的發展機遇，隨之而來的將會是產業互聯網時代的逐漸到來。而在整個 B 端產品的類目中，SaaS 產品作為企業級軟件中最集成的產品，也將隨著這股浪潮迎來爆發式的增長。
什么是 SaaS 產品？很多同學并沒有接觸過 B 端行業，平時用到的也都是 C 端產品，所以對 B 端產品的了解比較少。在 B 端行業最熱門的云計算領域中，目前普遍會分為三層架構。SaaS（Software as a Service–軟件即服務）；PaaS（Platform as a Service–平臺即服務） ；IaaS（Infrastructure as a Service–基礎架構即服務）。
附：云計算領域，三種不同的架構與對應的服務。
PaaS 基于 IaaS 實現，SaaS 的服務層次又在 PaaS 之上，三者分別面對不同的需求。越往上層，產品的集成度越高，提供的服務也就越豐富，而用戶所需要的自行解決的東西就越少。而最頂層的 SaaS 產品，便是用戶可以直接購買并使用的云端產品。
我們為什么要了解這些趨勢？
因為一個新的時代，對應一場變革，也將成為一次新的機會。不管是 SaaS 產品還是其他 B 端產品，都將在新的時代中逐漸得到重視。而 C 端產品的發展策略，也將迎來新的變化。對于許多設計師來說，這將會是一個新的機遇。
順勢而為，方能乘勢而上。
那么，在逐漸到來的產業互聯網時代，設計師需要注意哪些東西？設計思維又將進行如何轉變？
產業互聯網時代，意味著 B 端產品將得到重視，并與 C 端產品逐漸趨于平衡。因此，了解設計思維的變化，我們首先要從 B 端與 C 端產品之間，在產品設計與產品策略之間的差異性說起。
1. 服務對象的差異性
從服務對象來看，C 端產品的服務對象是人，產品的目標是針對人們生活方式進行的變革、升級。而 B 端產品的服務對象則大多是企業，目標是幫助企業進行商業效率的提升，從而產生價值。
服務對象的差異性，決定了產品在發展策略也將存在著較大的差異性。
2. 產品「打法」上的差異性
從宏觀的打法上看，消費互聯網時代會更求「快」，而產品互聯網時代則會更偏「穩」。
C 端產品的服務對象是人，而人的需求在個體差異性上相對變化較小，這就決定了 C 端產品通常都擁有廣闊的用戶市場。
因此，消費互聯網時代就像是資本在遼闊平原的角逐，長驅直入。講究快速占領市場，不斷地試錯、不斷地調整。從團購到直播，從打車到短視頻領域的興起，再到最后的單車大戰落幕。消費互聯網時代的每一次風口，都伴隨著各種「游擊戰」式的競爭。入場速度、快速調整能力、資本深度，都直接影響了最后的結果，而最終的結果也往往是勝者為王，敗者將快速地被市場淘汰。
B 端產品的服務對象是企業，而企業間的需求差異性則非常巨大，這就決定了 B 端產品通常需要較強的縱深能力。相對應的，其用戶群體在總量上就比較小、但也相對穩固。
因此，產業互聯網就像在崎嶇叢林的蹣跚前行，漸次演進，如同一場曠日持久的拉鋸戰。一方面，產業互聯網的鏈條非常長，需要長期的深耕、積累才能逐漸站穩腳跟。而這也導致了產品的壁壘足夠深厚，同類產品在短期內無法快速跟進。另一方面，企業間的差距需求的差異性非常大，因此產業互聯網存在非常多的細分市場，不同的產品各自在不同的賽道中深耕。而其最終的結果往往是百花齊放，各自盛開。
3. 整體行業的協同發展
雖然整個市場都不斷地強調——ToC 增長觸頂，ToB 是一片藍海。但這并非是「取而代之」，而是逐漸走向整體的「協調發展」。中國 ToB 的發展的一個重要根基，其實是「中國擁有世界上最成熟的消費互聯網體系」這一巨大的優勢。
因此，ToC 在很長的時間內，仍然會是互聯網的主力，而 ToC 市場的轉型，也將有賴于 ToB 產品所提供的服務。
而隨著中國將「互聯網+」政策上升為國家戰略，更是明確了以互聯網帶動傳統產業的發展方向。因此，互聯網的下半場，即產業互聯網時代的最終形態，將是互聯網與傳統行業的「融合式發展」。
ToB 產品將會成為帶動互聯網下一輪發展的核心驅動力。一方面幫助 ToC 領域完成轉型，進入更健康、更穩健的發展階段；另一方向，ToB 領域賦能傳統產業與互聯網相融合，并最終完成產業升級。
4. 產品形態的融合與趨同
整體產業的融合趨同，意味著產品的特性也將互相融合。一個很重要的現象是：C 端產品逐漸變得不那么 C 端了，而 B 端產品也越來越變得不像 B 端了。
比如 C 端產品的主流賽道中，隨著頭部產品的賽道日漸趨于穩定，其產品體量也因為業務擴展而不斷增加。同時，因為產品體系的逐漸形成，為了服務更多的 C 端用戶，會有越來越多的 B 類用戶進入平臺，而為了滿足 B 類商家的需求，產品的 B 端屬性變得越來越強了。
而隨著 B 端產品的不斷受到重視，原先不被重視的產品 UI、用戶體驗也逐漸在 B 端產品中得到加強。B 端用戶雖然服務于 B 端，但使用者終究是人。而隨著競爭的不斷加劇，原來的「重功能、輕體驗」思路逐漸式微。我們逐漸發現，許多 B 端產品長得越來越像 C 端產品了，甚至在 UI 和體驗層面做的與 C 端產品不相上下。
因此，隨著產品屬性的融合趨同，意味著設計思維勢必會與消費者互聯網時代存在差異。而我們的設計思維將不僅僅局限在誕生于消費互聯網時代的「用戶體驗思維」。我們需要更新的、更廣闊的設計思維，以滿足下一個時代的產品發展需要。
那么，新的思維是什么？它將從何而來？
從整個市場的協同發展，到產品形態的融合趨同。那么，我們的設計思維需要如何進行相應的變化？是同樣進行「融合趨同」，還是另辟蹊徑，尋求新的視角？
1. 關鍵詞提取
首先，不管設計思維如何變化，它一定需要同時滿足兩種產品設計思維的特性。通過前文的分析，我們可以在產品設計特性的維度，提取各自的關鍵詞進行分析：
產品體驗：誕生于消費互聯網時代的用戶體驗思維，在產業互聯網時代依然是產品設計中最重要的部分。無論是 C 端還是 B 端產品，用戶體驗必然是產品的核心競爭力，只有足夠好用、好看，產品才能獲得更多用戶，最終獲得商業上的成功。
靈活性：在消費互聯網時代，在激烈的競爭中，C 端產品的靈活性的打法對于產品的突圍至關重要。而未來的 B 端產品競爭將會加劇，這就需要 B 端產品也逐漸需要較強的靈活性。
成長性：產品的發展必將伴隨著不斷的變化，特別是具有一定體量之后，產品設計的成長性將至關重要。因此，產品的設計是否能夠預見未來發展，滿足不斷變化的產品形態，伴隨著產品不斷地成長，也將成為產品是否能夠持續獲得成功的關鍵因素。
產品效率：因為產品服務對象的關系，B 端產品一直是產品效率的代名詞。而在人口紅利消失與經濟下行的壓力下，產品效率將成為所有企業關注的重要因素之一。產品的效率不僅影響著企業的成本，也是產品競爭力的重要體現。
這四個關鍵詞，將會是我們在未來所需要關注的四個重點關鍵詞。越是往左，則「C」屬性越強，因為它更多地從用戶的角度出發，更關注用戶體驗。而越是往右，則「B」屬性越強，因為它更多地從企業的角度出發，更關注企業的長期發展。
2. 跳出單一層面，尋求新視角
在四個關鍵詞中，我們會發現，特性越是靠右，其所需要的整體性就越強。要滿足靈活性，就需要用戶體驗與產品策略相關聯。要滿足成長性，則要進一步結合底層的開發能力。而產品效率的提升，則需要產品的設計與不同層面都有著緊密的耦合。
在互聯網設計發展的過程中，我們從單點只關注視覺表層的「美工時代」，逐漸發展為關注線性的「用戶體驗思維」。在對于產品用戶體驗層面，確實有著長足的發展。
但是，單一層面的用戶體驗思維，在逐漸成熟的互聯網時代中，逐漸顯示出了一定的局限性。我們的價值局限于單一的體驗層面，我們似乎無法對產品形成更大的影響力，也難以為產品帶來體驗之外的更多價值。
因此，設計思維想要滿足新時代的需求，就需要同時滿足前文提到的四個關鍵詞。這就要求我們需要跳出單一層面，以全局的維度去思考產品的設計。
因此，全局性將成為未來的關鍵，我暫且將這種思維方式稱為——全局性設計思維。
全局性設計思維，即在設計過程中，始終能以更高的維度去審視全局，思考當下的設計。
何以全局，如何跳出單一層面？這種思維方式的前提，是你要首先了解整個產品（亦或是物體、組織等）的運行方式，清楚的知道整個產品需要達到的目標，從而準確、合理地對針對目前的局部做出設計，并最終構成整個完整的形態。
而「全局」的前提，是你擁有更高的眼界。你的眼界越高，你對產品、市場、甚至整個社會的洞察就越全面，你就能夠解決越大的問題，你能夠實現的價值就越高。眼界是基礎，解決更大的問題是目標，而全局性設計思維則是實現這個目標的方式與過程。
全局性設計思維，可以幫助我們跳出產品的單一層面，去思考從產品層、到體驗層、再到開發層這一完成的整體。讓設計滿足體驗層的同時，滿足產品層面的目標，同時讓產品的設計與開發高度耦合，將整個產品串聯成一個完成的整體。
好了，講了這么多，我們具體應該如何去運用全局性設計思維呢？
全局性設計思維，的應用方式非常廣泛。它并不是一個固定的方程式，而是一個更高層面的指導性設計思維，能夠通過不同的形式，來幫助你解決問題。
1. 全局觀——在生活思考更多可能
在嘗試這種思維之初，我們可以通過一些小的實踐，去鍛煉這種思維能力。
在日常的生活、工作中，其實我們有大量的事物可以練習和運用這種思維方式。比如你在裝修一個大房子，需要去選擇房子里的家具。當你在購買家具時，常規的思維方式是：這個家具在某個房間時應該是怎樣搭配的，所以我要購買什么樣形狀、顏色的家具，來滿足這個房間的需要。
但是，用這么思維方式來購買家具，將為對家具的靈活性與長期價值造成一定影響。從居住環境的長遠來看，也許這個家具有可能會因為某些原因，需要放到另一個房間，而它的形狀、尺寸、配色卻無法滿足其他房間的需要。最終，我們只能重新購買，或者接受一個風格、尺寸上并不搭調的房間出現。
因此，當我們在購買家具時，我們是否可以利用全局性設計思維，從整體空間的角度出發（而非單個房間），去思考如何讓家具滿足更多空間需求。長此以往，我們不僅可以打造一個風格統一的大空間，同時也能增加每個家具的利用率，在無形中也增加了這個家具本身的價值。
之所以舉家具這個例子，是因為這個原理與產品設計的原理非常類似。你可以將這個房子看成是整個產品，而家具則是不同的組件。通過不同的家具（組件），構成了我們的不同功能模塊（房間/功能區），而所有的功能模塊則構成了整個產品（房子）。
房子（產品體量）越大，房間/功能區（功能模塊）就越多，家具（組件）的多樣性、復雜性就越高，我們就越是需要從全局的角度去思考裝修的統一性（風格體系化）和家具的通用性（樣式組件化）。只有這樣，我們才能更好地去打造一個風格統一、體驗一致，同時又具備足夠自由調整空間的「大房子」。
2. 全鏈路——從全流程中重新思考設計
當你仔細地去理解許多非常著名的設計作品時。你會發現，幾乎所有優秀的、巧妙的設計，往往在設計中都體現了全局性的設計思維。它不僅僅解決著當前的問題，同時也能夠解決更大的問題，發揮巨大的價值。
比如著名的坂茂衛生紙的設計，看似普通，只是將衛生紙的軸心從圓形改成了方形，但它卻成為了舉世聞名的、公認的好的設計。為什么呢？
我們先了解一下這個設計為什么好。
首先，傳統的圓形紙卷拉出來的紙會比你實際需要的更多。而方形紙卷則由于阻力的作用，讓你用得更少，從而起到了解決資源的作用。其次，在運輸過程中，圓形的紙卷之間會產生很大的空隙，而方形紙卷則能夠緊緊靠在一起，提升空間利用率，從而起到降低運輸成本的作用。
這簡單的設計，居然發揮了如此大的作用。
那么，為什么我們在設計時就沒有考慮到這些問題呢？因為我們從最開始，就沒有從「紙」的整個全流程來去思考問題。
讓我們「站的更遠一些」，紙這個商品，并非只是我們見到的在商店售賣的那一刻。它從工廠中制造完成，通過運輸送到每個超市中，當我們購買以后，它又會在很長一段時間內，出現在衛生間，陪伴你使用的每一刻。我們可以將整個流程分為 3 個場景，而每個不同的場景，又將會對紙本身有著不同的影響。
當我們能夠考慮到衛生紙的運輸過程時，我們就可以通過設計去降低運輸成本；而當我們可以考慮到用戶的使用場景時，我們就可以通過設計，去提升阻力，降低使用量，間接地去提升用戶的使用體驗。而當我們通過全局性設計思維，可以同時解決這三個問題時，我們的設計就是好的設計，就擁有了更高的價值。
發現了嗎，為什么你沒有想到相同的設計方案？設計能力并不是關鍵，設計思維才是指引你做出好的設計的前提。當你能按上述的方式，去思考整個流程、不同的場景，我相信大多數的人都能夠設計出坂茂的設計方案，甚至比這個方案更好的解決方式。
通過前面的兩個案例，相信大家已經了解了全局觀、全鏈路兩種應用方式。
那么，我們最最最關心的問題——如何在業務中去使用這種思維呢？
在產品設計中，全局性設計思維也有著非常多樣化的使用方式和場景，在之后的文章中我也會講到很多應用方式。但是，在所有的方式中，我認為最為有效的，便是以全局性設計思維，幫助產品去構建一個完整的設計體系。
什么是設計體系？談及設計體系，大多數設計師會認為，設計體系就是設計規范?！覆痪褪钦覀€名次包裝一下規范嘛？」
我們為什么需要設計體系？它與設計規范有何不同呢？
設計規范是設計師最為熟悉的一種規范文檔。在產品設計時，優秀的設計師通常都會建立設計規范。然而在實際的項目中，設計規范往往無法難以有效實施。比如在開發眼中，規范并不符合開發規則，過于碎片化。而產品經理通常又不會去了解設計規范，因此在構建產品框架時也常常隨意發揮。
很多項目做到最后，設計規范僅存在于紙面的意義，并隨著項目的發展逐漸混亂。為什么會這樣？
因為不同職能間的思考方式存在差別，設計規范對于其他職能來說經常難以理解與運用，無法與其他職能形成有效聯動。
設計規范僅僅是基于視覺層面的規范，它是一個「平面」。而設計體系則是貫穿于產品的每個層面的、與產品深度結合的完整體系，它是「立體」的「有機生命體」。
設計體系的核心在于「體」，它是貫穿于整個產品的完整體系。設計體系由設計師創造，并深度融合于產品每個部分。它能夠讓產品更緊密、更統一、更有序，伴隨著產品的生長，與產品共同進化，并最終推動產品的發展。
創造并推動這一體系，則要求設計師需要更全面的能力。只有充分地去理解并參與產品的每個部分的設計，才能讓設計真正延伸至產品的每個部分。
而創造這一切的前提，便是全局性設計思維。
羅馬不是一天建成的，設計體系也是如此。設計體系的建立是一個漫長的過程（與產品體量相關），需要在前期投入更多的精力。但若是你的方法得當，就會在項目中越來越輕松，并以此形成良性循環，而你也會越來越有成就感。
如何正確地去構建設計體系呢？我在這里總結了幾個要點：
樹立觀念
首先，樹立長期的體系化意識是必要前提。在任何項目中都要時刻保持體系化思維，著眼于整個項目，去尋找體系化的推動時機。當你在潛意識中擁有這種思維之后，你會自然而然的將其植入到設計中。
以解決問題為導向
體系化并非憑空建立，而是建立在解決問題的基礎之上。設計體系的本質，就是由無數個標準化的解決方案，最終構成的一個完整的體系。因此，我們要以解決問題為導向，以全局性思維去思考問題的本質，最終建立適用于全局設計體系。
以小為始，重視質量
腳踏實地，從小處入手，去發現產品中最基礎的一些問題。表面上看這些問題，對項目影響不大，但他們數量龐大，加在一起便會嚴重影響整個產品的效率。因此，我們要首先建立高品質的基礎體系，再以此為基礎構建更大的體系。
不要一開始就設法建立一個巨大的體系，那樣只會是一盤散沙，因為它的結構是無序、混亂、不健康的。而這也是大多設計規范缺乏有效性和可實施性的根源。
梅拉妮·米歇爾的《復雜》一書中講到，任何復雜系統，都是由無數個體通過簡單的算法所構成的。在算法領域也是同樣的原理，一個優秀而強大的代碼，必然是由無數個小型模塊，通過簡單的算法耦合形成巨大的代碼矩陣?；A算法越強大、代碼結構越「健康」，可擴展性和靈活性就越強，其能力就越強大。
從規范入手，由面到體
從本質上來說，設計體系是由「多個層面的規范」組合而成的。因此，由設計師推動的體系化建設，往往最初都是從設計規范這一「單層規范」開始。但是，設計體系的建設需要將單層的規范，通過不同的方式，轉化為不同層面的規范，最終由面到體，形成體系化。
換位思考，尋求跨職能合作
設計體系的建立與維護，通常需要多職能的通力協作。因此，我們需要經常換位思考，在完成設計的工作，幫助其他職能完成目標。只有這樣，才能得到更多的信任，并以此為基礎推動更多體系化的建設。
比如我在設計一個功能模塊的頁面時，首先會與不同模塊產品經理進行交流，了解不同的業務需求，并從產品層面就開始尋求統一性與通用性。這樣的話，當其他模塊需要同一個功能時，前端便可以直接復用，同時后端的數據也可以進行互通。而在開發端，我也會詳細了解不同端的開發實現原理，務求設計規范與開發規則在理解上的一致性。這一既方便了開發理解規范，同時也從根本上提升了開還原的準確性。
長此以往，整個團隊就能夠建立良好的溝通和互信關系。有了這種默契，設計體系的推動就容易多了。
保持優化，不斷成長
設計體系的另一個重要價值在于，它是可以伴隨產品不斷成長的。所有產品都是在發展中不斷變化的，過分僵硬的規則，將會對產品發展起到反作用。
在業務發展中，產品一定會不斷地加入新的功能模塊，并對原有頁面作出相應的調整。因此，設計體系需要時刻與產品策略保持一致，及時與上下游職能溝通，不斷地針對產品發展進行優化，以保證設計體系能夠符合產品的發展需要。
使用正確的推動方式
體系化最終能否成功實施，推動的方式至關重要。
在日常的項目中，大多數的業務方對設計體系了解甚少，也難以體會其中的價值。因此，他們通常會認為這些東西毫無必要，多數情況也不太愿意配合體系的推進。如果強行推進，反而會引起不必要的阻力，招致反感。那么，我們應該如何正確的去推進設計體系建設呢？
為他人帶來價值：首先，尋找雙方共同的利益點是首要任務。也許是可以讓其他職能的工作更，也許能夠促使其達成 KPI，再不直接，那也一定能夠為整個產品帶來價值（不然你也沒必要推了）?？傊O計體系一定要能夠為他人帶來價值，這樣才能順利推進。否則人家憑什么要協助你推進，因為你美麗可愛嗎？你也可能比較可愛，但總歸是不能一直這么來吧。
在解決問題后提出方案：不要一開始就啪一下拋出一個「宏大的理想」，大部分人會覺得你不切實際。你只需要通過這個體系，幫助業務方先解決一個問題，然后再提出你解決方式的來源——一個嚴謹的、可驗證的、長遠價值的體系化解決方案。
尋找合適的推動時間：最后，對于設計體系來說，尋找到正確、恰當的推進時機至關重要。比如當你在平時突然想要提出，對現有品牌進行升級時，大多數業務方都會認為你是沒事找事。而如果情況是在新的一年中，產品進行了概念的升級，這時候你將概念以及未來的品牌規劃融入在你的方案中，再去推進品牌升級，就會容易很多了。
-本文旨在引導大家更好地理解和學習這種思維方式，想要用好全局性設計思維，光靠講是遠遠不夠的。最重要的是能將這種思維帶入到產品中，為業務帶來更大的價值。
因此，在后續的幾篇文章中，我將通過不同類型案例，為大家深入講解全局性的具體實踐案例。
全局性設計思維 | 如何打造強大的品牌體系
為什么要建立品牌體系？品牌體系有哪些價值？設計師應該如何推動品牌體系的建立？
本文將帶你了解網易智慧企業品牌體系的建設與推動全過程，聊一聊品牌體系建設的那些事兒～
FishDesign組件庫 | 從零到一構建企業級UI組件庫
我們為什么要建立組件庫？在產品的什么階段需要組件庫？如何抽象業務組件？組件庫設計過程中有哪些重要的細節需要注意？
本文帶你深入了解，網易 Web 端組件庫——FishDesign 組件庫從零到一的完整全過程。
全局性設計思維 | 如何構建事業部級大型設計體系
設計體系有什么價值？如何基于不同的業務建立設計體系？設計師如何推動體系化建設？在體系化過程中有哪些需要注意的地方？
我將會在這篇文章中，為大家介紹網易智慧企業設計體系構建全過程。
樣式組件化+規范體系化，形成產品設計體系，整體重構產品線。
結合品牌體系，推動事業部更多產品加入體系，形成智慧企業 Web 端產品設計體系。
推動更多產品/業務融入體系中，讓智慧企業設計體系不斷成長，賦能業務發展。
好吧，似乎文章又寫得偏長了一些。只能說，想要認真地講清楚一個道理，確實不是一件容易的事情。
設計思維本身并不復雜，但想要講清楚它的背景、原理及價值，就需要把它整個掰開來講。而為了確保設計思維的可實施性，又需要經過大量的實踐研究，自己能夠走通以后，才能與大家分享。
坦白講，似乎整個社會都在追求快節奏、碎片化閱讀。但若是因此而喪失了自己學習的節奏，那么等于是沒有節奏的，你的知識體系也將是東拼西湊，無法形成一套完整的體系。這也是我更新比較慢的原因之一，希望大家讀完文章，能夠切實地得到一些東西，這就很有意義。
文章來源：優設 作者：Jady13
QQ 游戲中心經過設計改版之后，我們重新設定了整體的世界觀——多彩的游戲宇宙。并且對多個模塊及內容進行了新的設計升級，其中也包括重要的圖標圖形。
1. 延展思考
因此基于目前較為完整的圖標圖形，希望可以拓展出更多不一樣的設計內容，并且可以應用在不同的位置，例如空白頁、運營內容、背景等等。
2. 問題分析
基于目前的圖形可以很明顯的得到 2 個問題：
3. 設計啟發
3D作為 2020 的主流設計趨勢之一，可以很好地表達設計氛圍。因此想嘗試跨次元的設計方式，從 3D 圖形的角度去思考，嘗試更多可能性。
下面主要是分享我在制作 3D 圖標中的一些方法和流程，以及 2D 與 3D 圖形設計中思考的差異性，希望可以跟大家互相學習，一起探討這方面的設計。
雖然是 3D 的圖標，但實際上使用到的軟件包括有：Cinema 4D（C4D）、Sketch、Photoshop（PS）、illustrator（AI）。
整體的大概流程：
3D 與 2D 最大的差別在于多一個維度來表達圖形，因此我們在 2D 向 3D 轉化的過程中，需要思考一些基本的原則，并且結合這些規則，降低 3D 圖標與 2D 圖標違和感。在這次的 3D 圖標中我總結了以下幾條基本規則。
1. 圓變球
在 3D 軟件中表達圓有 2 種方式：球體、圓柱體。在實際的設計中，我們需要根據實際情況判斷是否變成球體或者圓柱體，這里建議單體呈現的圓形設計成球體，在這種情況下球體相比圓柱體更能表達圓形的視覺感受。
例如下面氣泡的例子，球體化的表現比圓柱體化的表現更加飽滿，光影效果更加豐富。
2. 方變塊
與上面的規則比較接近。當我們在 2D 圖標中使用矩形之類的圖形，建議使用立方體來表達。優點：立方體可以增加圖標上的細節表現；增加厚度更有利于光影的表達。
例如下面禮物的圖標，我們在實際的 3D 場景下應該更貼合現實生活中的認知，設計成禮物盒子的效果。
3. 結合實際認知
除以上的 2 種建議之外，我們在實際建模的時候還需要結合實際認知而定。例如金幣、游戲卡的設計應該是帶有厚度的片形；錢包設計成折疊的效果。
4. 適當簡化圖形
2D 圖標向 3D 圖標的轉換過程中，需要適當進行簡化，一些不必要的內容可以適當進行刪減。主要的目的是：
5. 增強空間思維
2D 的圖標只有一個平面，因此大部分情況下是一種「紙片性」的思維，常規的 2D 向 3D 的轉換思維是增加厚度，但實際上出來的效果并不理想。因此在轉換的過程中，需要使用空間的思維去思考，在 3 維的空間中應該是怎么樣的。例如下載和收件箱的圖標，常規的思維可能是在 2D 的圖標上增加厚度，但轉換成空間思維就是讓其具有立體感和空間感的形體。
6. 圖標狀態補充
在實際建模的中會發現，很多模型在靜態下是可以進行簡單處理的，但結合動態或實際認知，就需要相關細節狀態補充。例如禮物和寶箱圖標的開蓋效果，因此把實際的蓋子和盒子/箱子的模型做出來，以便于動畫的實際表達。
在進入 C4D 之前，需要清楚不同圖形可以使用什么方式建模，因此我們可以進行一個簡單的分類，分為：常規圖形和異形。兩種圖形在建模中的方式會有一些小差異，當然一個圖標也可能包含這兩種類型，因此實際操作中可以靈活處理。
1. 常規形：使用基礎物體建模
部分簡單的有規則的圖形，可以直接使用 C4D 的基礎物體（例如：立方體、球體、柱狀體、錐體等），通過對基礎物體的調整后得到模型，例如下面的圖形。
案例展示
2. 異形：AI路徑+擠出
在實際操作的過程中發現部分模型較難通過基礎形調整得到，或是直接建模會比較耗時。因此我們可以導入 AI 路徑再擠出的方式來得到我們的模型。例如下面的圖形
案例展示
基于以上的以上 2 種類型的圖形，這里分享一下制作的過程和心得?？赡懿粔蛉?，但希望大家可以一起來補充互相學習。
1. 對齊中心點
基礎建模對齊中心軸點是一切開始的重中之重，這里會涉及到很多后續的調整和其他命令的應用（例如擠出、對稱等命令）。例如一些中高階的人物建模也是非常依賴中心點對齊來實現對稱命令的。
2. 結合圖像
在 C4D 視圖本身具有多視圖，可以結合不同視圖導入不同視角的平面結構進行制作，常見情況下的建?？梢詫肴晥D（例如角色、人物之類的）。而圖標相對來說是很簡單的，所以這里只應用正面視圖即可，其他的視角可以自行腦補后制作。
結合圖像的好處：
操作流程：正視圖下快捷鍵 shift+V 調出視圖背景——選擇背景——添加圖像?；蛟谝晥D選項中調出，然后配置即可。
3. 結合路徑
如上圖標類型中的描述，部分異形的圖標如果直接在 C4D 中繪制會相對耗時，因此我們可以結合路徑的方式，再使用擠出的命令來實現我們想要的模型，這樣可以大大提升異形物體建模的效率。
C4D 中對 AI 的圖層只會讀取顏色的邊緣，然后生成路徑。因此在 AI 中編輯的路徑，依據實際的情況選擇填充或者描邊，然后再拖拽進 C4D。如下產生的效果對比，左邊為填充圖形，右邊為描邊圖形。
操作流程：使用 AI 導出 8.0 版本的路徑——拖拽進 C4D——添加擠出命令——設置擠出高度及封頂樣式。
4. 使用變形器
一些簡單的形變可以通過變形器的應用，得到我們想要的造型。例如下面的案例，外星人臉是在圓形的基礎上使用 FFD 進行調整，而寶箱則在方形的基礎上使用錐化來達到圓弧的效果。
C4D 的渲染效果主要是依賴于材質和燈光的配合，熟練者往往可以依靠經驗有效率的制作，但我們也可以通過鍛煉總結出一些常用的材質參數或者布光的位置來提率。因此我也從這次的 3D 圖標制作中總結了一套關于材質和布光的方法。
C4D 場景的主光源我們可以通過全局光照+天空的方式來營造整體的氛圍，這組光的特點在于具有比較柔和的效果，并且模擬自然的環境光效。
全局光照開啟后，需要依賴燈光、天空光來對物體進行照射，如果設定后未增加燈光或者天空，在渲染時只能渲染出一片黑色。（全局光照——主要是模擬真實的光照效果，通過光源投射到物體上再經過無數次的反射和折射出來的效果，因此也能解釋為什么只加全局光照渲染不出來內容。）
操作流程：渲染設置——效果——全局光照
添加天空增加天空作為基礎光照補充
操作流程：地面快捷入口——選擇天空——添加材質球——勾選發光——添加 HDR 貼圖。
下面通過一些案例對比來看看全局光照及天空的對比效果
全局光照-開和關的差異
從下面的案例我們可以明顯看到差別，全局光照關閉后的圖標相對暗淡一些，整體圖標的光反射也相對減弱了許多。
有無天空的差異
天空有助于增強圖標的光感，添加天空后整體圖標的細節和質感也相對更加豐富。相對，無天空整體圖標質感則有所下降。
天空是否增加HDR貼圖的差異
添加 HDR 貼圖可以增強場景內物體的環境反射，讓物體材質更加豐富增強細節質感。在一些強反射的場景下非常依賴 HDR 貼圖的使用。從以下案例對比，可以明顯看到差異性。
整體添加三盞燈光來營造整體的場景氛圍。主要分為：主光（最強）、補光（增強陰影面的亮度）、背光（補充背面環境的光源，增強環境光氛圍，勾勒輪廓）。在實際的場景中可以根據實際的反射效果和氛圍，調整燈光的位置、與物體的間距、明暗度。
燈光對于物體的作用會隨著顏色的差異，產生的光亮度也會有所差異，因此在實際的使用過程中，對于燈光的位置、反射的細節都可以進行微調來達到最優的效果。
色相的對比：不同色相在同樣的燈光作用下產生的效果具有稍微較小。
明暗的對比：深色和淺色在同樣的燈光作用下產生的效果差別較大。
實際案例對比：從下面的實際案例對比可以明顯看出同樣燈光下不同色相的明顯差別，綠色的兩部產生過度曝光。因此可以通過調整燈光的距離或者亮度來解決這一問題（如上面燈光分布建議）。
3D 圖標由于相對簡單，材質上主要使用顏色和反射的配合就可以得到不錯的質感。當然如果希望在質感表現上更加豐富，亦可考慮增加其他的內容項來進行補充
顏色的設定
圖標的顏色基本上與原圖標的顏色保持一致，但部分顏色但實際渲染效果會存在些許差異，因此我們在材質上也可以根據視覺效果進行微調，視覺上保持統一的顏色感受。例如禮物的圖標，如果按原來的顏色，亮部會過渡曝光，因此適當提高了亮部顏色的飽和度。
顏色偏差
在 3D 的場景內是通過各種光與顏色的反射而成的，因此即便同樣的顏色，在實際渲染出來的 3D 圖標和 2D 圖標也會存在一定顏色偏差。
反射是本次 3D 圖標中材質非常重要的一環，基本的效果都是來源于對反射的設定。整體主要設定了反射的類型、粗糙度、反射強度、高光強度、層遮罩的顏色。由于圖標的顏色并不完全一致，因此在粗糙度、反射強度、高光強度是一組動態的參數。
參數變化的對比
如下面的案例，針對不同顏色的圖標在粗糙度、反射強度、高光強度上都有差異性，因此不是說設定好一組參數之后就那個完全適用所有的顏色，因此這里會根據實際情況調整，但整體的視覺效果保持一致。
層遮罩的設定差異
除了基礎的反射類型及參數，還需要在層遮罩中添加菲涅耳來增強反射的豐富度。默認的菲涅爾是一組黑白的顏色材質，我們可以通過調整暗部的顏色來增強圖標的顏色飽和度和豐富度，如下案例對比。
靜態的 3D 圖標顯得精致，增加動效之后的 3D 圖標則除精致外，還更加富有趣味性和新鮮感。3D 的動效與 2D 有著明顯的差別，可以更多維度地思考物體的運動軌跡、變化方式。
首先我們需要根據不同造型對需要制作動效的圖標進行簡單的分類，這個分類的主要作用在于明確不同圖標的動效設計方式，為動效的設計方式進行鋪墊。根據已有的圖標劃分為：單體形、組合型、拼裝形。
單體形
圖標以單個或單組形體呈現，或者整體造型屬于某個已存在的事物或者形體，整體圖形內容具有不可切割性。
組合型
圖標通過兩組或兩組以上的圖形內容組合而成，圖標由主形（圖標實際的外輪廓造型）和點綴圖形（用于圖標表意或者提升圖形內涵）組合而成的圖標，圖標可進行拆分或者重組后形成動效。
拼裝形
圖標本身可能在現實中不存在的事物或物體，通過創意思考而得到的圖形，圖標的動效更具有可發散性和可重塑性。
結合上面的類型差，在設計動效的時候也會稍稍不同。重點在于表達不同的圖標具有的特性，因此我們可以根據這些特性去設計圖標的動畫方式。
自體運動
對應單體圖形，圖標動效通過自身的位移、旋轉、形變而產生，這類圖標的動效比較靠近現實生活中接觸的感知或圖形動效本身具有普適性認知。例如火箭升空、UFO 飛碟、放禮炮、開寶箱等。
組合運動
對應組合圖形和拼裝圖形，多圖形運動組合而成，圖標的多個部件可從不同軸向開始進行不同的軌跡運動，最終進行完整的圖標融合。各個部件本身可能也存在位移、旋轉、形變等動效，可以更大程度豐富圖標的動效表現。
部件運動
整體動效相比前面兩種類型較為簡單，通過某個圖標上的部件運動來表達動效的內容，因此這個部件需要是圖標上較為明顯的圖標特征，這樣更能讓人具有記憶點。
音效是這次 3D 圖標設計的點睛之筆，結合音效可以更加豐富地表達圖標動效的趣味性。不同的圖標動畫反饋出來的音效是不一樣的，因此賦予對應的音效反饋才是更合理的表達。
1. 選擇音效
在實際的配置音效的過程中發現，部分圖標比較難找到相關聯的音效。但我們可以通過較為類似或者可以表達出該圖標動畫過程中的聲音反饋的音效。例如活動小禮炮用的是開葡萄酒塞的聲音，開寶箱用的是開門的聲音，飛碟（UFO）用的是一組電子音效等等，并且從相關聲音中竊取其中一段需要的。
2. 組合音效
部分圖標的動畫效果很難通過一條音效進行表達，因此需要疊加 2 組或者 2 組以上的音效來豐富整體的感受。例如手柄人圖標疊加了三組不同的音效來表達，游戲卡疊加 2 種不同的音效。
3D 的圖標或 3D 類型的內容如何與 UI 結合？相信大家也時有思考這方面的內容?；谶@次的 3D 圖標設計，我也進行了初步的嘗試，從幾個方面來簡單聊聊這方面的內容。
1. 3D圖標對于UI設計的作用
在嘗試之前，我們需要明確 3D 內容對于 UI 設計作用是什么？我簡單總結了幾個關鍵點：
2. 3D ICON X Tab bar
當我們設計 Tabbar 的時候，首先想到的表現方式往往是有趣的圖標圖形設計、結合動效之類的方式。但我們或許也可以考慮使用 3D 的圖標+動畫的方式來表達我們的設計。
3. 3D ICON X 運營內容
一些相對簡單的運營內容，我們可以考慮將元素進行 3D 化設計，這樣可以一定程度增強整體運營的視覺表現力。
4. 3D ICON X 空白頁插圖
3D 插圖是 2020 的設計趨勢之一，結合 3D 的插圖讓整體的設計更加具有氛圍感。
5. 3D ICON X COVER
將背景中的某些元素結合 3D 圖形進行設計，讓整體的氛圍更加具有空間感和立體感。
本次結合實際項目中的內容進行不同維度的設計嘗試，并且希望，可以從中去尋找到更多設計的可能性和突破點。當然這只是系統化設計思考中的一步，但可以啟發后續更加深入的 3D 設計探索。
文章來源：優設 作者：ID設計站
前言
前面幾篇我們就 Redux 展開了幾篇文章，這次我們來實現 react-thunk，就不是叫實現 redux-thunk 了，直接上源碼，因為源碼就11行。如果對 Redux 中間件還不理解的，可以看我寫的 Redux 文章。
實現一個迷你Redux（基礎版）
實現一個Redux（完善版）
淺談React的Context API
帶你實現 react-redux
為什么要用 redux-thunk
在使用 Redux 過程，通過 dispatch 方法派發一個 action 對象。當我們使用 redux-thunk 后，可以 dispatch 一個 function。redux-thunk會自動調用這個 function，并且傳遞 dispatch, getState 方法作為參數。這樣一來，我們就能在這個 function 里面處理異步邏輯，處理復雜邏輯，這是原來 Redux 做不到的，因為原來就只能 dispatch 一個簡單對象。
用法
redux-thunk 作為 redux 的中間件，主要用來處理異步請求，比如：
export function fetchData() {
return (dispatch, getState) => {
// to do ...
axios.get('https://jsonplaceholder.typicode.com/todos/1').then(res => {
console.log(res)
})
}
}
redux-thunk 源碼
redux-thunk 的源碼比較簡潔，實際就11行。前幾篇我們說到 redux 的中間件形式，
本質上是對 store.dispatch 方法進行了增強改造，基本是類似這種形式：
const middleware = (store) => next => action => {}
在這里就不詳細解釋了，可以看 實現一個Redux（完善版）
先給個縮水版的實現：
const thunk = ({ getState, dispatch }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState)
}
return next(action)
}
export default thunk
原理：即當 action 為 function 的時候，就調用這個 function (傳入 dispatch, getState)并返回；如果不是，就直接傳給下一個中間件。
完整源碼如下：
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) => next => action => {
// 如果action是一個function，就返回action(dispatch, getState, extraArgument)，否則返回next(action)。
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}
// next為之前傳入的store.dispatch，即改寫前的dispatch
return next(action)
}
}
const thunk = createThunkMiddleware()
// 給thunk設置一個變量withExtraArgument，并且將createThunkMiddleware整個函數賦給它
thunk.withExtraArgument = createThunkMiddleware
export default thunk
我們發現其實還多了 extraArgument 傳入，這個是自定義參數，如下用法：
const api = "https://jsonplaceholder.typicode.com/todos/1";
const whatever = 10;
const store = createStore(
reducer,
applyMiddleware(thunk.withExtraArgument({ api, whatever })),
);
// later
function fetchData() {
return (dispatch, getState, { api, whatever }) => {
// you can use api and something else here
};
}
總結
同 redux-thunk 非常流行的庫 redux-saga 一樣，都是在 redux 中做異步請求等副作用。Redux 相關的系列文章就暫時寫到這部分為止，下次會寫其他系列。
一、前言
前端的模塊化規范包括 commonJS、AMD、CMD 和 ES6。其中 AMD 和 CMD 可以說是過渡期的產物，目前較為常見的是commonJS 和 ES6。在 TS 中這兩種模塊化方案的混用，往往會出現一些意想不到的問題。
二、import * as
考慮到兼容性，我們一般會將代碼編譯為 es5 標準，于是 tsconfig.json 會有以下配置：
{
"compilerOptions": {
"module": "commonjs",
"target": "es5",
}
}
代碼編譯后最終會以 commonJS 的形式輸出。
使用 React 的時候，這種寫法 import React from "react" 會收到一個莫名其妙的報錯：
Module "react" has no default export
這時候你只能把代碼改成這樣：import * as React from "react"。
究其原因，React 是以 commonJS 的規范導出的，而 import React from "react" 這種寫法會去找 React 模塊中的 exports.default，而 React 并沒有導出這個屬性，于是就報了如上錯誤。而 import * as React 的寫法會取 module.exports 中的值，這樣使用起來就不會有任何問題。我們來看看 React 模塊導出的代碼到底是怎樣的（精簡過）：
...
var React = {
Children: {
map: mapChildren,
forEach: forEachChildren,
count: countChildren,
toArray: toArray,
only: onlyChild
},
createRef: createRef,
Component: Component,
PureComponent: PureComponent,
...
}
module.exports = React;
可以看到，React 導出的是一個對象，自然也不會有 default 屬性。
二、esModuleInterop
為了兼容這種這種情況，TS 提供了配置項 esModuleInterop 和 allowSyntheticDefaultImports，加上后就不會有報錯了：
{
"compilerOptions": {
"module": "commonjs",
"target": "es5",
"allowSyntheticDefaultImports": true,
"esModuleInterop": true
}
}
其中 allowSyntheticDefaultImports 這個字段的作用只是在靜態類型檢查時，把 import 沒有 exports.default 的報錯忽略掉。
而 esModuleInterop 會真正的在編譯的過程中生成兼容代碼，使模塊能正確的導入。還是開始的代碼：
import React from "react";
現在 TS 編譯后是這樣的：
var __importDefault = (this && this.__importDefault) || function (mod) {
return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
var react_1 = __importDefault(require("react"));
編譯器幫我們生成了一個新的對象，將模塊賦值給它的 default 屬性，運行時就不會報錯了。
三、Tree Shaking
如果把 TS 按照 ES6 規范編譯，就不需要加上 esModuleInterop，只需要 allowSyntheticDefaultImports，防止靜態類型檢查時報錯。
{
"compilerOptions": {
"module": "es6",
"target": "es6",
"allowSyntheticDefaultImports": true
}
}
什么情況下我們會考慮導出成 ES6 規范呢？多數情況是為了使用 webpack 的 tree shaking 特性，因為它只對 ES6 的代碼生效。
順便再發散一下，講講 babel-plugin-component。
import { Button, Select } from 'element-ui'
上面的代碼經過編譯后，是下面這樣的：
var a = require('element-ui');
var Button = a.Button;
var Select = a.Select;
var a = require('element-ui') 會引入整個組件庫，即使只用了其中的 2 個組件。
babel-plugin-component 的作用是將代碼做如下轉換：
// 轉換前
import { Button, Select } from 'element-ui'
// 轉換后
import Button from 'element-ui/lib/button'
import Select from 'element-ui/lib/select'
最終編譯出來是這個樣子，只會加載用到的組件：
var Button = require('element-ui/lib/button');
var Select = require('element-ui/lib/select');
四、總結
本文講解了 TypeScript 是如何導入不同模塊標準打包的代碼的。無論你導入的是 commonJS 還是 ES6 的代碼，萬無一失的方式是把 esModuleInterop 和 allowSyntheticDefaultImports 都配置上。
初始化
使用 https://github.com/XYShaoKang... 作為基礎模板
gatsby new gatsby-project-config https://github.com/XYShaoKang/gatsby-hello-world
Prettier 配置
安裝 VSCode 擴展
按 Ctrl + P (MAC 下: Cmd + P) 輸入以下命令,按回車安裝
ext install esbenp.prettier-vscode
安裝依賴
yarn add -D prettier
Prettier 配置文件.prettierrc.js
// .prettierrc.js
module.exports = {
trailingComma: 'es5',
tabWidth: 2,
semi: false,
singleQuote: true,
endOfLine: 'lf',
printWidth: 50,
arrowParens: 'avoid',
}
ESLint 配置
安裝 VSCode 擴展
按 Ctrl + P (MAC 下: Cmd + P) 輸入以下命令,按回車安裝
ext install dbaeumer.vscode-eslint
安裝 ESLint 依賴
yarn add -D eslint babel-eslint eslint-config-google eslint-plugin-react eslint-plugin-filenames
ESLint 配置文件.eslintrc.js
使用官方倉庫的配置,之后在根據需要修改
// https://github.com/gatsbyjs/gatsby/blob/master/.eslintrc.js
// .eslintrc.js
module.exports = {
parser: 'babel-eslint',
extends: [
'google',
'eslint:recommended',
'plugin:react/recommended',
],
plugins: ['react', 'filenames'],
parserOptions: {
ecmaVersion: 2016,
sourceType: 'module',
ecmaFeatures: {
jsx: true,
},
},
env: {
browser: true,
es6: true,
node: true,
jest: true,
},
globals: {
before: true,
after: true,
spyOn: true,
__PATH_PREFIX__: true,
__BASE_PATH__: true,
__ASSET_PREFIX__: true,
},
rules: {
'arrow-body-style': [
'error',
'as-needed',
{ requireReturnForObjectLiteral: true },
],
'no-unused-expressions': [
'error',
{
allowTaggedTemplates: true,
},
],
'consistent-return': ['error'],
'filenames/match-regex': [
'error',
'^[a-z-\\d\\.]+$',
true,
],
'no-console': 'off',
'no-inner-declarations': 'off',
quotes: ['error', 'backtick'],
'react/display-name': 'off',
'react/jsx-key': 'warn',
'react/no-unescaped-entities': 'off',
'react/prop-types': 'off',
'require-jsdoc': 'off',
'valid-jsdoc': 'off',
},
settings: {
react: {
version: '16.4.2',
},
},
}
解決 Prettier ESLint 規則沖突
推薦配置
安裝依賴
yarn add -D eslint-config-prettier eslint-plugin-prettier
在.eslintrc.js中的extends添加'plugin:prettier/recommended'
module.exports = {
extends: ['plugin:prettier/recommended'],
}
VSCode 中 Prettier 和 ESLint 協作
方式一:使用 ESLint 擴展來格式化代碼
配置.vscode/settings.json
// .vscode/settings.json
{
"eslint.format.enable": true,
"[javascript]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint"
},
"[javascriptreact]": {
"editor.defaultFormatter": "dbaeumer.vscode-eslint"
}
}
ESLint 擴展會默認忽略.開頭的文件,比如.eslintrc.js
如果需要格式化.開頭的文件,可以在.eslintignore中添加一個否定忽略來啟用對應文件的格式化功能.
!.eslintrc.js
或者直接使用!.*,這樣可以開啟所有點文件的格式化功能
方式二:使用 Prettier 擴展來格式化代碼
在版prettier-vscode@v5.0.0中已經刪除了直接對linter的集成,所以版沒法像之前那樣,通過prettier-eslint來集成ESLint的修復了(一定要這樣用的話,可以通過降級到prettier-vscode@4來使用了).如果要使用Prettier來格式化的話,就只能按照官方指南中的說的集成方法,讓Prettier來處理格式,通過配置在保存時使用ESlint自動修復代碼.只是這樣必須要保存文件時,才能觸發ESLint的修復了.
配置 VSCode 使用 Prettier 來格式化 js 和 jsx 文件
在項目中新建文件.vscode/settings.json
// .vscode/settings.json
{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
}
說實話這個體驗很糟糕,之前直接一鍵格式化代碼并且修復 ESLint 錯誤,可以對比格式化之前和格式化之后的代碼,如果感覺不對可以直接撤銷更改就好了.現在必須要通過保存,才能觸發修復 ESlint 錯誤.而在開發過程中,通過監聽文件改變來觸發熱加載或者重新編譯是很常見的操作.這樣之后每次想要去修復 ESLint 錯誤,還是只是想看看修復錯誤之后的樣子,都必須要去觸發熱加載或重新編譯,每次操作的成本就太高了.
我更推薦第一種方式使用 ESLint 擴展來對代碼進行格式化.
調試 Gatsby 配置
調試構建過程
添加配置文件.vscode/launch.json
// .vscode/launch.json
{
// 使用 IntelliSense 了解相關屬性。
// 懸停以查看現有屬性的描述。
// 欲了解更多信息，請訪問: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Gatsby develop",
"type": "node",
"request": "launch",
"protocol": "inspector",
"program": "${workspaceRoot}/node_modules/gatsby/dist/bin/gatsby",
"args": ["develop"],
"stopOnEntry": false,
"runtimeArgs": ["--nolazy"],
"sourceMaps": false,
"outputCapture": "std"
}
]
}
的gatsby@2.22.*版本中調試不能進到斷點,解決辦法是降級到2.21.*,yarn add gatsby@2.21.40,等待官方修復再使用版本的
調試客戶端
需要安裝 Debugger for Chrome 擴展
ext install msjsdiag.debugger-for-chrome
添加配置文件.vscode/launch.json
// .vscode/launch.json
{
// 使用 IntelliSense 了解相關屬性。
// 懸停以查看現有屬性的描述。
// 欲了解更多信息，請訪問: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Gatsby Client Debug",
"url": "http://localhost:8000",
"webRoot": "${workspaceFolder}"
}
]
}
先啟動 Gatsby,yarn develop,然后按 F5 開始調試.
收集了一些工作中常用的工具。
如果你有好用的工具或者有意思的工具網站，要留言哦！
藍藍設計的小編 http://www.syprn.cn