設計師要懂技術,那應該懂多少,懂哪些

2022-05-27 分類：網站建設

我在還是學生的時候就看過這張圖片，當時的我感覺自己一不小心探尋到了世界的真理，宇宙的真諦，只要我到達了圖中的那塊綠色區域，成為一名優秀的設計師指日可待。于是乎我開始各種學習，起早貪黑披星戴月日夜兼程嘔心瀝血，對于各種知識無比渴求，可是后來我慢慢發現，這樣漫無目的“學習”并不能讓我抵達綠色區域，它分散了我太多的精力。

人的時間和精力都是有限的，學習一切并不現實，這張圖片最終沒能讓我一下子就變成一個超超超厲害的設計師。

“設計師要懂一些技術。”對呀，要懂一些技術，可是，一些，是多少?懂多少，才算懂?

這個問題其實誰也沒有一個非常準確的答案，如果非要說有的話，那么肯定是越多越好，可首先你要明確自己是一名設計師，既然你是做設計的，你就不能真的像程序員一樣去學習代碼。對于設計師來說，懂技術，似乎也并不需要你真的做到能夠親手打代碼才叫懂。將骨架脈絡摸清，以及之間的交互和聯系弄懂(注意這并不是淺表皮毛的意思，這里已經足夠大部分沒有計算機背景的設計師童鞋們學習好久了，不過也總比你幻想著去學碼代碼輕松太多)，才是設計師能夠比較“舒適地”切入的一個點。

這篇文章寫給我自己看，也分享給各位有需要在這個方面提升的童鞋。由于本人學的是計算機相關專業，所以這篇文章只講技術這一塊。接下來就盡量具體地講講要想做到傳說中的懂技術，我們需要關注什么，不需要關注什么。在開始之前送大家一碗由國內某開發大神熬制的毒雞湯，“學習總是痛苦的，如果你沒有感覺到痛苦，那可能你并沒有學到。”做好準備，上車、出發。

1. 懂“棧”

我們常見的功能，其實大部分可能需要幾種技術同時協作才能夠達成，這些個技術就是棧。就好像我們在畫圖的時候，有可能需要數個圖層的合并才能做出這種效果來。譬如說，當用戶在使用我們設計的美美的登錄頁面進行登錄操作時，后面的程序已經風起云涌。

判斷用戶是否已經在文本框里面輸入了東西，如果沒有，彈出toast提示用戶先進行輸入，如果有，那么進行第二步。

嘗試發送用戶輸入的賬號密碼，如果斷網了的話提示用戶網絡有問題，如果沒有，進行第三步。

將用戶輸入的賬號密碼傳輸到我們的服務器(服務器其實就是一臺電腦)，讓服務器來判斷賬號密碼是否正確。

服務器判斷完畢，通過網絡告訴用戶這邊的app賬號密碼是否正確。

用戶這邊的app接受到了服務器判斷的結果，如果正確，給登上，如果不正確，則提示用戶賬號或密碼錯誤。

登上之后給服務器通知一下，這名用戶已經登上了。

這時候服務器知道用戶已經登上了，它可能會通知別的服務器來辦他繼續接客，當時也有可能自己接著接客，接客就是為用戶繼續服務。

看看，總共七步(注：在現實情況下遠遠不止這幾步，這個例子只是為了更加簡單的介紹棧是什么)，這個過程中有許多的棧參與了進來，有幫忙做記錄的，有幫忙把信息發出去的，有幫忙接受信息的，也有幫忙通知其他棧的，總之每個棧都很勤奮，但是整個過程速度非常之快，不信你登qq試試。

怎么切入?——先找你的程序員問問，讓他細致告訴你程序背后運作的過程和使用到的技術，然后拿筆記下來。英語還湊合的自己去Google一下，不湊合百度也可以，先大致了解下這種技術到底是什么、用來干嘛的、為什么現在程序員會用這個、各種技術之間是怎么協作的之類。剛開始的時候不用太刻意地去深入了解各個細節，自己總結個大概就行。(譬如上面這個登錄的例子，你可能會問出一個叫做Retrofit的玩意來，那么你就去查查Retrofit是干嘛的。)

為啥要懂這個?——在設計工作開始前期，你就能夠大致知道某些功能可能需要哪些技術來實現比較好，是用H5好?還是直接native寫好?因為你知道H5的優劣勢，也知道native的優劣勢，結合業務的需求你能很好的去權衡、去判斷，構建出來東西才能大程度上如你所愿。

而當程序員在討論如何構建這個功能的時候，你至少能夠大致跟得上別人的腳步，當你學得足夠多的時候，你應該可以做到能夠聽得懂他們在講什么，問題出在哪里。但是要注意，聽就好，千萬別亂給意見，越是細節方面的意見越要謹慎，因為假如他們是有水平的程序員的話，大部分情況下不會需要一個設計師來提程序方面的意見。

2. 懂系統架構

如果說棧代表的是各個技術的話，那么這個其實我們可能都聽過的系統架構，**就是決定這些技術之間的合作的方式的東西。**上面舉出的那個例子涉及了非常多的棧，也談到了它們可能每個負責的任務，可單個單個的棧無法辦成任何事情，它們之間是需要相互溝通交流的，好的架構能夠讓它們更加有效地溝通交流，就好像一家公司，光有技術上乘的員工沒用，做出一個好的產品還需要公司有良好的管理。

怎么切入?——同樣地你又要來勞煩你的程序員寶寶了，讓他給你畫一張關于你們產品架構的架構圖。

畫出來的東西可能看起來又復雜了一點，但是別慌，讓他大致給你講講這些都是些什么東西。一些可能是用來處理網絡請求的，一些可能是用來收集數據的，一些是用來處理數據的。

不管你信不信，了解你們公司產品背后大致的技術架構對你來說非常有用。(你就再也不會做出讓程序要給你做一個商城，跟淘寶差不多就行這些事情來了。)

為啥要懂這個?當你開始對架構有了一定的了解，你的思路也會變得清晰起來，同你一樣，程序員處理事情的方式各有不同，但是整體的架構指導著他們的大方向，讓幾個程序員做出來的東西跟一個程序員做出來的東西一樣。懂的系統架構的設計師不會貿然就來個大改，因為在一開始之前他們就會更加謹慎行事，為界面層面的架構著想，如果有能力，也為后端層面的架構著想。

總的來說，架構非常重要，一旦定下將決定產品大致的走勢。所以設計師要帶著發展的眼光和堅定的信念來進行設計，因為技術人員們會根據你的設計來設計架構，根據你想要的效果來設計架構，假如一個產品從設計開始就非常復雜而且冗余，那么一個產品的架構也會非常復雜而且冗余(這就是為什么我一直認為交互設計師其實應該深入地了解一點技術知識，因為交互設計師不僅能夠決定界面布局，他們還能夠很大程度上左右系統的架構，盡管有時候你自己都沒察覺到)，當你意識到自己的設計有這么多缺點，想要進行一輪大改，撥亂反正的時候，通常程序已經積重難返，深陷泥潭了。

補充一點，在大一點的公司里面，系統架構可能需要數個部門協作完成，要學習的東西還是比較多的，要跑的地方還是比較多的，加油吧各位。

3. 懂數據模型和API

你的產品通過一套特定數據模型來組織自己的數據，在你的產品里面，數據以某種特定的格式進行流通。在技術的范疇里面，數據這兩個字幾乎代表一切東西，比如說用戶的id，是一條數據，用戶點過贊的數百首歌曲，是一組數據，連用戶今天有沒有點這個按鈕，也是數據。對于我們來說，一個使用我們產品的真真實實的人代表用戶，而對于我們的程序來說，一個由：用戶名、用戶id、用戶賬號、用戶密碼、用戶手機號、用戶身份證號組成的一組數據代表一位用戶，而這寫數據通過某個數據模型組成在了一起。

上文說到棧和棧之間會相互溝通傳遞，它們溝通傳遞的就是數據。數據模型的概念至關重要，譬如說你使用你的賬號密碼來登上淘寶，然后再點擊購物車，這時候你能夠看到自己要買的商品，因為你的賬號跟你要買的東西早已被通過某種格式記錄了下來，淘寶通過賬號密碼知道了你是誰，而又通過你是誰來查詢你在購物車里面放了些什么，這里就有兩個數據模型，一個是用戶數據模型，一個我們暫且叫它購物車數據模型。你可以理解成兩張excel表格，一個表格記錄你的賬號密碼，一個表格記錄你想買的東西，這個時候我先要知道你是誰才能知道你想買的東西是什么。數據跟數據之間的共享需要一個叫API的東西，中文名通常叫接口。

接口負責將它底下的數據傳遞給有權調起它自己的人(很高冷)。你要聽歌的時候，你會點擊qq音樂里面的某首歌曲，這時候app向服務器發起請求“用戶要聽這首歌辣!”，qq音樂服務器找到對應的接口返回數據，數據包括：這首歌、這首歌的專輯圖片、這首歌的歌手名、這首歌的歌詞等等。

但qq音樂就不能調起網易云音樂的接口，因為qq音樂沒有這個權限去調起，盡管能夠調起，qq音樂也不一定能夠正常播放，因為返回回來的數據模型qq音樂無法解析，道理大概類似盡管你有歌詞你也不會唱日文歌一樣，因為，不懂!

當然世界不會那么的冰冷，例如說蘋果自帶的地圖從iOS10開始就調用了高德地圖的地圖數據(不信打開看看去)。這是為什么?因為他們合作了。

所以，接口也分為公用接口和私有接口，公用接口可以供任何人使用，就好像追波，它們會提供一系列的公用接口，所以盡管它們沒有官方客戶端，但是我們依然能在市場上下載到制作精良的追波app。而私有接口就只供某個產品使用了，但是如果有商業上的合作的話，你也能拿到別人的接口，使用別人的數據，實現一些本來不能實現的功能。

怎么切入?——第三次去請教你的工程師寶寶了，建議帶上一些零食(推薦可樂)，這時候他們可能會讓你去找你們公司的后臺開發人員。讓后臺開發人員給你一份關于你們產品的api文檔(這里可能包含了與你們有商業合作的公司提供給你們的api)，你會發現api文檔其實沒有那么復雜，英語水平良好的你其實也能看懂大部分意思，這個時候你了解了你們產品背后的若干個api，同時間還能了解到背后的數據模型。

為啥要懂這個?——知道你手頭上有什么數據，就好像一個廚師知道自己的菜籃子里面都有一些什么食材，知道有什么材料廚師就知道大概能做一桌子怎么樣的菜，知道你手頭上有什么借口和數據之后你才能知道自己的產品大概能做到什么、做不到什么，有這個數據我們要如何加以利用、沒有這個數據我們要怎么去得到。例如，你知道你們的產品能夠獲取的到歌曲的專輯圖片，你就設計出一個位置來放置這張圖片。可如果你設計出一個很大的位置來放置專輯的圖片，并在上面添加上了無語倫比的效果，整個頁面看起來簡潔又不失華麗、精致卻凸顯大氣，最后才發現我們并沒有這個數據，整個頁面乃至于與之相關的所有頁面都恐怕要重新設計了。當然這個例子搞笑成分比較重，但是反問自己，是否或多或少都遇到過這樣的事情?

4.你不需要去懂的東西

編程。我想所謂的懂技術≠會編程，你不需要懂編程，盡管會編程會顯得你很酷，但是一個設計師不必要用能夠親自上手編程這個技能來裝點自己。當然假如你覺得自己有興趣，那么你大可以去學習，這非常不錯，不過千萬不要拿來上班用。你可以自己開發一個app，然后以個人項目的名義上架各大應用市場，這樣看起來才是真的酷!

不是每個設計師都能夠在蘋果或谷歌(雖然沒有接觸過，但是我相信別人的設計師也是懂技術的，因為國外的設計專業很多都有混雜著一些CS課程)這樣的公司工作，他們或許有足夠多的時間金錢精力和能力去實現設計師的大膽創新的設計，我們大部分人沒有這樣的條件，有些東西不是你逼著程序員加加班就能弄出來的。但是你也不必沮喪，設計師不必每時每刻都在發明新的東西，大部分情況下，我們能將產品基本的功能做得很靠譜就已經非常不錯了。為什么?因為這已經夠難的了。

所以，放下你的浮躁，靜下心來學習，學習能讓你看到更多以前看不到的問題!

分享標題：設計師要懂技術,那應該懂多少,懂哪些
網站地址：http://www.js-pz168.com/news14/159814.html

成都網站建設公司_創新互聯，為您提供網站排名、網站營銷、網站改版、標簽優化、網站制作、微信小程序