起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識你不應該錯過的技術&設計知識點
編輯導語：我們在日常工作中需要多進行總結，才能夠在工作中得心應手、游刃有余、減少犯錯的可能性。本文作者就分享了在工作中接觸技術崗位以及設計崗位的經驗，總結了技術和設計的相關知識點，希望看后能夠對你有所幫助。
本篇內容筆者總結了工作中，通過接觸不同設計崗位、技術崗位人員，了解和學習掌握的相關設計與技術知識，以及溝通交流的經驗與技巧，希望能對各位有所幫助！
一、設計知識點
1. 概要
作為產品工作者，與設計師協作，是產品建設過程中必不可少的一環。
筆者結合工作中與UI設計師、交互設計師等合作的經驗與感悟，分享一些與之友好、高效協作，并提高對你認可度的“訣竅”。
2. 筆者的“訣竅”
- 了解設計理論知識；
- 熟悉設計的交付件；
- 掌握各端設計規范。
以上做到，不僅能使你在產品設計時更具審美高度，人機交互意識；同時也會讓你在與UI設計師和交互設計師等進行溝通時，如魚得水，如虎添翼，容易得到較高的認可與信任！
3. 了解設計理論知識
每個行業都有相應的行業理論知識，UI設計和交互設計都有相應的設計理論知識，這些知識是作為產品設計人員的你&我應該了解的。
不僅能幫助我們在思考產品時有的放矢，更能幫助我們同設計同事達成一致，更好、更快的推進產品進程。
那么，都有哪些作為產品設計人員需要了解的設計理論知識呢？
筆者總結如下：
- 平面設計理論知識：logo（標志）設計、配色設計、字體設計、圖文布局設計等；
- 界面設計理論知識：web端設計、移動端設計等；
- 交互設計理論知識：web端交互、移動端交互等。
現在信息通達，資源豐富，有很多的書籍和網站可以學習和了解以上設計理論知識，在此列舉一些筆者讀過的相關書籍和常用的設計網站資源：
- 平面/界面設計書籍：《標志設計》、《色彩設計》、《字體設計》、《Grid systems 平面設計中的網格設計》、《品牌至上》、《西文字體》、《寫給大家看的設計書》、《寫給大家看的設計書》等
- 交互設計書籍：《觸動人心：設計優秀的iphone應用》、《點石成金：訪客至上的網頁設計秘笈》、《方寸指尖：移動設計實戰手冊》、《在你身邊，為你設計》、《用戶體驗要素》、《設計心理學》、《瞬間之美》、《錦繡藍圖》、《About Face3 交互設計精髓》、《UCD火花集》、《交互設計沉思錄》、《情感化設計》、《簡約至上》、《贏在用戶》等
- 設計網站資源：Dribbble、Behance、站酷、UI中國、花瓣、Iconfont、千圖網、昵圖網、海洛創意等
通過了解這些知識，在實際工作中，能給我們產品工作者帶來哪些幫助呢，筆者總結如下：
1）建立一套相對豐富的、成體系的設計理論知識
能夠幫助自己在做產品設計的時候，從無到有的整個進程中，都能夠做好設計層面的把控；從界面到交互，都有自己基于理論知識的理解與思考。
這樣保證設計的產品是有理論支撐的，首先能夠讓自己信服。
2）增加信任感
產品設計人員交付的原型或者是在與不同階段的設計同事進行溝通時，都能夠站在專業的角度，與之平等交流。
比如：產品人員交付的原型、界面間的鏈接邏輯、功能間的跳轉等交互、界面的基本布局等。
為什么會這樣設計，大到整個產品，小到一個控件，都能夠道出相應的緣由和設計依據。有足夠的理論知識支撐，將會更加讓人信服，而不會給人一種臆想般的自嗨感。
3）與平面設計同事（有的公司沒有單獨的平面設計崗位，由UI設計兼任）交流時，主要是關于產品logo設計，產品相關宣傳冊設計，宣傳海報設計等
如果你了解平面設計的一些理論知識，那么你在和對方交流時，就不會信息不對等，顯得不專業。
比如：交流logo設計時，可以提出一些設計參考。
參考的依據可以是：
色彩搭配和諧，貼合產品定位和行業屬性，是需要圖形logo，圖文結合型，還是文字logo；交流宣傳冊設計時，可以提出對封面（首頁）設計，版式，主題色選取，內容頁排版風格，圖文搭配比例等的思考；宣傳海報的設計，清楚不同場合的尺寸要求，風格和版式等有較為明確的需求。
當然能夠引導設計師發揮能力，創作出超出預期的作品，也是需要基于設計理論探討出來的。
4）與UI設計同事交流時，主要是關于產品界面配色，界面布局等
如果你能夠了解web端和移動端以及其它硬件終端的UI設計理論知識，那么你和設計的溝通效率，執行效果都將會提高很多。
比如：對于web端的UI設計，你能夠對web頁面的配色、不同字體大小、不同網站布局風格、網格系統理論、格式塔原理等都有所了解；并結合自己對產品的理解，有一定的設計思路。
對于移動端的UI設計，不同端的字體設計單位、模塊間的間距規律、按鈕大小、行間距、元素間距等、閃屏頁、廣告banner、網格系統、格式塔原理等設計知識有所了解。
5）與交互設計同事交流時，主要是關于產品界面間的交互邏輯，控件間的交互邏輯等
如果你能夠了解web端和移動端的UI設計理論知識，那么你和設計的溝通效率，執行效果都將會提高很多。
比如：對于web端的交互設計，是基于鼠標的點擊、滾動等操作。
頁面的滾動方式、模塊的滾動方式、按鈕的默認、懸浮、點擊的不同狀態、控件點擊后的反饋形式（彈窗、Toast、定位、新頁面等）的設計，產品設計人員需要有一定的了解；對于移動端的交互設計，是基于用戶手指的滑動、點擊、長按等操作。
頁面的滑動，模塊的切換方式，按鈕的不同狀態（默認、點擊、長按、禁用等），控件點擊后的反饋形式（彈窗、Toast、定位、新頁面等）的設計，產品設計人員需要有一定的了解。
4. 熟悉設計的交付件
同產品設計崗位一樣，各個設計崗位也有對應的需要產出的設計交付件。筆者準備闡述的不僅僅是結果性的交付件，也包括與設計合作過程中，一些過程性的交付件。
對此，筆者總結如下：
1）結果性交付件
UI設計視覺稿。
UI設計師根據產品設計人員提供的原型圖，進一步美化設計的文件，包括配色、布局、控件、彈窗、banner以及不同內容字號的設計等內容。
作為產品設計人員，你需要熟悉這些元素，并能夠同自己在設計的原型文件時進行的表現層的思考結合，分析出UI設計師產出的視覺稿交付件是否達到預期，是否有超出預期的地方。
這些判斷能力都是必要的（UI設計師需要配合輸出視覺設計規范，產品設計人員可以就此文件與設計人員進行深入探討）。
2）結果性交付件
交互設計稿。
UE設計師（用戶體驗/交互設計師）會根據產品設計人員提供的原型圖和需求文檔進行交互設計（也有可能產品人員兼任交互設計的情況）。
包括頁面間跳轉、跳轉方式、跳轉等待期間的動效設計；跳轉失敗的提醒設計、頁面滾動或滑動形式、彈窗動效；頁面加載動效、控件點擊動效等。
這一系列的動效設計，除了看其表象（呈現樣式），還需要深入了解實現方式和具體參數。
比如：一張圖點擊后，放大查看的動效，雖然都是點擊后放大的樣式；但是實際上，UE在設計的時候，花的心思往往是你不易察覺的。
同樣是點擊放大查看效果，不同的動效節奏和運動曲線，造成的細節體驗區別會是很明顯的。
你需要同交互探討動效組成部分，每個部分的意義，運動曲線是怎樣設計的，緩進緩出各自所用時間等；甚至自己能夠在結合理論知識的基礎上，通過動效網站，動效設計軟件進行效果模擬，同UE深入交流。
3）過程性交付件
圖標資源。
不管是web端還是移動端，圖標資源都是必須產出的。
從圖標樣式是否符合產品主題、風格是否統一、圖標形式是面型還是線型，以及不同終端圖標的輸出格式（移動端一般需要五種不同倍數的圖標用于適配）。作為產品人員，對這些的要求和評估都需要足夠熟悉。
4）過程性交付件
點9圖。
點9圖是一種移動端設計中比較特殊的產出文件（研發人員也有點9圖制作工具），一般用在需要保證元素縱向或橫向拉伸不變形的情況下，比如：非規整的聊天框，隨著字數的增多會拉長或拉寬，如果不做成點9圖，那么就會造成變形、邊緣模糊等。
所以掌握點9圖知識，知道怎么制作點9圖，或者自己會制作點9圖，也是不錯的技能。
5. 掌握各端設計規范
各端都有屬于對應的設計規范，該設計規范交付件一般會由UI設計師產出，產品設計人員能夠熟悉這些規范，對協作和評估規范嚴謹性是大有裨益的。
根據不同終端屬性，可以分為web端UI設計規范和移動端UI設計規范等，而設計規范一般需要包含：
1）色彩設計規范
所使用的色彩種類，主色與輔色的搭配；
2）文字用色規范
所使用文字的顏色，不同的應用場景應該搭配相應的顏色、一級標題、二級標題、內容、提示、備注等；
3）文字字號規范
所使用文字的字號（大小），不同的應用場景應該搭配相應的字號、一級標題、二級標題、內容、提示、備注等；
4）ICON（圖標）規范
所使用的icon設計規范、不同的應用場景、ICON的不同用色、是面型還是線型，都需要相對統一、成體系；
5）控件設計規范
包括輸入框、按鈕、滑桿、頁卡、開關等控件，同一類型的控件，需要統一設計規范，形成一套體系；
6）間距設計規范
不同頁面，同類型間距的尺寸需要統一，符合規律；
7）交互設計規范
包括滾動，滑動（上下/左右等），點擊反饋，彈窗動效等的交互設計，同一場景的交互樣式，需要保持統一。
二、技術知識點
1. 概要
時至今日，作為產品工作者，如果還在疑問產品需要不要懂技術？
那么筆者可以肯定的答復你：需要！
為什么？
產品的idea或者用戶的需求能夠實現，都依賴于技術的實現。沒有技術，idea就是空中樓閣，更談不上后期的運營等等；從技術的重要性，我們也能體會到，懂技術是多么重要且必要的一件事情。
產品在工作過程中，要將idea、需求等落地到技術實現，就必定要同不同終端的技術人員協作，這其中包括：前端研發人員、后端研發人員、數據庫設計人員、算法工程師、數據工程師、運維人員、架構師等。
需要協作的技術人員越多，你需要了解、學習、掌握的相關技術知識也就越多，筆者結合工作中與以上這些技術工程師們合作的經驗與感悟，分享一些作為產品工作者，應該掌握的技術知識。
2. 筆者的理解
1）了解相關技術知識
2）總結技術交流思路
3）“越俎代庖”不可取
以上做到，不僅能使你在產品設計時，思維發散的同時，兼具技術實現視角考慮問題；在面對領導或客戶對于技術實現或工期預估的疑問時，能夠結合團隊技術實力，給出具有可行性、可靠性的方案.
同時也會讓你在與各端研發工程師進行溝通時，不僅能從產品設計角度把控方案，更能從技術實現方式、方案等方面進行深入探討；包括技術方案的可行性，對有實現難度的地方能夠評估是否可突破和采取備選方案等！
3. 了解相關技術知識
各端技術都有自己的開發語言、框架、工具等，這些開發語言、框架、工具就像是工程師手中的刀與劍，助他們攻城略地。
工作中，筆者接觸到的各端工程師及其相關技術知識有：
- web前端技術知識：開發語言（Html、Css、Js、Ajax、js等），技術框架（jQuery、Bootstrap、Vue、nodeJs等），開發工具（IDEA、Webstorm、Sublime、記事本等等）；
- 客戶端技術知識：開發語言（C#、C++等），技術框架（WPF），開發工具（Visual Studio）；
- Android端技術知識：開發語言（java），開發工具（Android Studio）；
- Ios端技術知識：開發語言（Objective-C、Swift），開發工具（Xcode）；
- 后端技術知識：開發語言（PHP、Java、Shell、go、sql等），數據庫（Mysql、Sqllite、Postgres、Redis等），技術框架（Mybatis、Springboot等），開發工具（IDEA、eclipse、Maven、gradle等）；
- 大數據技術知識：Hadoop、Hive、ZooKeeper、HBase、Kafka、Scala、Azkaban、Python、Docker等；
- 其他技術知識：接口調試（postman）、CI/CD（jenkins、gitLab）、虛擬機（VmWare）、Markdown、GitHub（代碼托管服務平臺）、碼云（云端軟件研發協作平臺）、Linux、git/svn。
以上列舉的這些技術相關知識（并未完全列出），并不是要求產品人員做到能夠像研發人員那樣，通過編譯器進行實際性的編碼工作。而是希望能夠對這些知識有所了解，知道是用來做什么的、解決什么問題；最好是能夠看懂簡單的代碼，熟悉一些語言和工具。
比如：
1）有些web前端代碼，通過F12調試工具，可以自行進行簡單的代碼調試和代碼查看、理解，甚至分析出現的問題，即使看不懂，也可以反饋給研發人員定位分析；
2）有些后端代碼設計邏輯，你能夠做到通過查看研發人員編譯器里的源碼，同研發人員一起分析在產品設計層面的思路，落地到研發實現環節出現不一致的地方，定位問題，進行修正；
能夠通過編寫常用的sql語句進行數據查詢與分析（復雜的也能夠通過渠道快速解決），比如：一些簡單的數據統計，用戶總人數，日活躍/月活躍人數等。
雖然現在可以通過第三發數據統計平臺、自建統計系統等方式實現各類數據的統計與分析。但是從數據庫層面直接獲取數據信息的能力是一項不錯的能力，尤其是產品初期這些現成的可視化分析平臺都沒有接入或建成的時候。
3）了解一些語言之間的差異性，在做技術選型、技術評估的時候，能夠知其然也知其所以然；
比如在決定是選擇Mysql數據庫還是Sqllite數據庫的時候，就能夠同研發人員一起結合實際情況進行評估。
Sqllite數據庫對于小數據量的數據處理效率較高，但因為是單線程處理方式，數據量較大時處理效率降低明顯，遠不如Mysql數據庫的多線程處理效率。
4）了解大數據量、高并發場景下數據處理技術；
比如消息處理，Kafka就是一種高吞吐量的分布式發布訂閱消息系統，其在大數據研發應用上的目的是通過Hadoop的并行加載機制來統一線上和離線的消息處理，也是為了通過集群來提供實時的消息。
5）了解git和svn的差異，git是分布式的版本控制系統，是按元數據方式進行存儲，現在很多互聯網公司的研發團隊都是采用git進行版本控制。
svn是集中式的版本控制系統，是按文件方式存儲，分支也與git不同，現在也有不少企業使用svn做版本控制，也包括團隊內部文檔版本集中管理。
當然，需要了解的技術知識遠遠不止筆者上面提到的這些，以上僅僅只是舉例說明而已。
那么，我們能夠通過哪些渠道去獲取相關的技術知識呢？
現在信息通達，資源豐富，有很多渠道可以學習和了解以上各端技術相關知識，在此列舉一些筆者常用的技術網站資源（讀過的書籍就不列舉了，各位可針對不同的語言查詢相關書籍學習）：
- 學習類網站：w3cschool、菜鳥教程、慕課網等；
- 工具/資料類網站：掘金、StackOverFlow、知乎、博客園、CSDN、V2EX、開源中國等。
通過這些網站，你可以快速、系統化的了解一門語言及其相關應用的基本知識和最新發展動向。
在實際工作中，遇到一些在與研發人員交流溝通過程中新的知識點或者技術問題，可以默默記下來，通過這些網站查找相關技術帖子，獲取相關知識；既能增加自身的技術知識儲備，也能不斷拓寬和加深與技術交流的內容廣度和深度（全面和細節）。
透過這些技術帖子，了解技術前沿知識，擴充技術視野的同時，跟進研發人員技術觸角。
三、總結技術交流思路
產品崗位需要接觸很多不同終端的研發人員，與之交流，這些交流可能是發生在不同的場景下：比如技術選型、技術方案探討、技術實現與產品設計有出入時、技術復盤、技術分享等情況下。
這些交流思路看似零散，實則有其相關性，每個人的理解可以能不一樣，總結的思路或許也有所出入。
此處筆者僅分享個人的理解，總結如下：
1. 牢記“交流定式”
同下圍棋一樣，再復雜多變的棋局也有它的一些套路，圍棋里稱為“定式”。筆者將之沿用到與技術交流的過程中，也有一些作為產品人員，在交流之前就能考慮到的一些“交流定式”。
這些“定式”包括針對類似問題的解決思路，以及對于出現的問題能夠做的相關思考部分。
比如：
當出現技術實現邏輯問題時，我們可以向技術反饋該問題，并提出問題是否出在代碼實現的邏輯有誤的想法，幫助技術快速定位問題；
當輸入內容校驗有誤時，我們可以推測出現問題的原因可能是校驗規則有誤或不完善，甚至是正則判斷待優化等引起，可以提供給技術人員相關思路；
當每次加載頁面資源都需要等待逐一加載完成時，可推測技術實現沒有利用緩存機制或異步加載機制；
登錄訪問失敗時，如果不是網絡問題，可推測是否接口掛掉或是后臺服務器出了問題；
頁面加載信息資源，沒有數據返回，可推測是該數據請求接口出了問題等。
2. 找準“高手助陣”
學會借勢是工作中不可或缺的能力，此處僅分享與研發人員交流時如何借勢，借勢即假借高手的“勢”來幫助自己解決問題。
有些時候，我們在與研發人員交流過程中，難免碰到“硬茬子”，不全是指研發人員，更多時候是指問題棘手的情況，自己所理解的那點技術知識完全cover不了對方；這個時候為了打破僵局，你得學會找到能夠解決該問題的人，可能是項目經理，技術Leader等。
但是到底誰能解決，就看你平時對他們技術能力和涉及領域的了解程度和關系處得怎么樣了，這些在這種關鍵時候都是派上大用途的！
3. 跳出“死鎖狀況”
工作中不是所有問題都能在第一時間給出解決方案的，很多時候都需要經過之后的深思熟慮，多番探討后才有結果。
與研發人員溝通不外如是，不管是在正式會議，還是在針對性解決問題的時候；遇到討論后，短時間給不了解決方案的情況，一定要能夠及時跳出來，脫離“死鎖狀況”，釋放資源，將該問題納入后續待解決的“池子”。
四、“越俎代庖”不可取
切記：千萬別越俎代庖！
別認為自己對相關技術知識有所了解，就將重心傾斜到技術向。這樣做不僅會讓共事的研發反感，認為你在他專業領域插手太多，指指點點，也會讓你在做產品思考時，不自覺的被團隊技術能力所限制。
所以，把握好分寸更為關鍵、重要。畢竟了解技術知識是為了幫助我們更好的做好產品，和研發更好的共事服務的。這些都需要在實際工作中，大家靈活應對。
五、總結
以上就是筆者關于——“你不應該錯過的設計&技術知識點”的分享內容，希望對各位有所幫助。
總而言之，就是希望各位能夠多邁出一步，去了解對方行業相關知識，提高工作效率的同事，提升協作雙方的滿意度。
作者：nickChen，微信公眾號：薪火雜記
本文由 @nickChen 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基于CC0協議
干貨滿滿