為什麼我建議 UX/產品設計師學習寫程式?

我一直想要寫這篇文章。

一方面因為我認為在設計的路上 coding 真的讓我受益匪淺,另一方面是學 coding 直接導致我架了自己的網站,然後跌跌撞撞踏上設計這條路。

這篇文章是一篇心得統整 — 以 UX/產品設計師的角度,分享寫程式為我帶來了哪些好處。我主要整理了三點:設計效率、更多接觸不同東西的機會以及溝通能力

先強調一下,我認為會寫程式不是產品設計師「應該」要有的技能之一。但我想無論將來你想走管理職、IC或當Freelancer,會寫程式都能大大地幫到你。

設計效率

我是個好奇心很強的人。這體現在我生活中的方方面面,當然也在我的工作之中。

每次在設計開始前,我都會盡可能去了解我所設計的東西背後各個系統之間如何溝通、交換資料,這讓我感覺很安心。

但這也對工作有非常實際的幫助。因為我可以從這些流程與資料裡推敲出我的設計應該要涵蓋哪些設計狀態,需要處理哪些特殊狀況。

會寫程式讓我可以獨立做到這一點(至少一部分)。

我也可以粗略地區分出某種設計在技術實踐上的複雜度,所以就不用浪費時間在探索不切實際的方案上。

當然我還是需要與工程師重複確認自己的猜想,以防止推斷有誤。不過因為我對系統有一層基礎的認知,所以與他們溝通起來時總是可以很有效率。

這種差異長期下來會非常明顯。我發現自己與其他設計師相比,更能有效地預估設計專案所需的時間;在進入開發之後,也可以減少反覆溝通、補件或是修改的次數。

這些省下來的時間可以被用來做更多的研究、學習與方案嘗試,或是提早下班。

接觸更多不同的東西

回想起來,我經手過的專案類型之多元自己都有點兒意外。

除了一般 To C 的體驗設計之外,我也參與過資訊安全、CMS、人臉辨識、商品推薦、數據儀表板的專案。我想如果不是我身上有「懂一些技術」的標籤,大概不會有這些機會。

能夠接觸到不同性質的專案是非常可貴的,尤其是在職涯初期。因為這時候你可能還在探索自己真正感興趣的方向在哪裡。

我覺得就算在同一間公司做相同的主題,不同的專案也會有很大的差異。這些差異可能會體現在目標用戶、行業知識、設計慣例甚至是工作流程上。差異有時候大到根本像是換了一個產品。

如果沒有實際執行過,其實很難了解之間的差異。

除了探索方向之外,多元的工作經驗在申請其他工作時也是一個加分的項目。尤其現在的產品越來越細分,許多公司都在尋找有特定經驗的設計師 — 汽車、SAAS、Data, etc。

很多時候僅僅是一個設計項目就可以拉開你跟其他候選人的距離而讓你雀屏中選。

溝通

我的工作經驗大多是在中小型的公司,設計師與工程師會很頻繁的溝通設計上的需求與規格。在進行這些設計溝通的時候,我需要以對方最容易聽懂的方式表達,這樣才可以避免誤解或是浪費時間。

舉例來說,在講解設計的時候我會特意把「樣式」、「會用到的資料」以及「狀態&用戶流程」分開來講,讓前端、後端與QA工程師可以分別專注在適當的地方。當我認為某項設計可能帶來反彈或疑慮的時候,我甚至會提前找好資源或範例。

如果缺少對程式碼的了解,我應該無法做到這些。我的專案也就可能受到更大的阻力,讓我沒辦法達成目標。

雖然讓人有些氣餒,但我發現在工作上大家都會有意無意的抗拒改變。因為改變時常伴隨著更多的工作、溝通與風險。

身為需要推動改變的人,我們只好找方法把它們變得更好入口。

而且我想如果你的目標是晉升成管理職,那這個能力似乎不可或缺。因為你會需要更多跨部門的支持,尤其像是工程師們這樣的直接合作對象。

其他的幫助

在工作之外,會寫程式對我還有其他大大小小的幫助。

像是用 Webflow 做作品集就需要對程式有基本的了解;前幾個月幫朋友架了個 WordPress 網站,全部弄好好交給他也令我感到很開心。

有時候我也會為自己寫一些提升工作效率的小工具 — 像是 Todolist, 番茄鐘等等。當然市面上一定有更好的,但自己做東西讓人很有成就感呢。

其實學 Coding 很快、很好玩,成本也很低

學 Coding 資源真的很多,甚至在 Youtube 上面就可以找到。但如果要學的話,建議選定一家認真的機構並且註冊課程。授課方式大多會是影片與實作的混合,我自己偏向越多實作越好。

如果找到合適的學習方式,你會發現需要的時間其實短得讓人驚訝。我當初在學的時候,網頁前端入門大概只花了幾個晚上的時間就完成了。

當然這是很基本的程度,就像認識食材之於烹飪一樣。但過了這個階段,你就可以開始用各種食材拼湊出不同的料理了!

這是一件讓人非常有成就感的事呢。無論你是不是設計師,應該都有過自己動手做東西,並且引以為傲的經驗吧。會寫程式之後你的小小程式可以在自己的電腦上執行,也可以分享給家人或朋友。

所以今天就開始吧!

我個人推薦先從網頁前端開始,因為它好理解、不用特別的開發環境、可以快速看到作品讓人成就感滿滿。

在學習的過程中你也可以順便學到 Server、Client、Request 等等概念,不管你將來設計 Web, App, To C, To B的產品都會很受用的。

平台的話我推薦Codecademy,不是業配,連分潤連結都不是 T___T

寫在最後

前幾天聽 Podcast,剛好也聽到其他人討論這個主題。

我發現大多數人對這件事的概念都很類似 — 如果會的話很好,但不會也無仿,反正自然會累積。

但我覺得如果早晚要學,為什麼要零散地在各個專案中東撿西湊,而不一開始就有框架、有系統地學習呢?

所以我建議設計師們學習怎麼寫程式,只需要抽出一些些的時間就可以有巨大的回報。我相信你的世界會非常的不一樣。

鄭斐凡 Ian Zheng | UX & Product Design

謝謝你閱讀到這裡。如果喜歡我的文章,請拍手、追蹤或是訂閱我的Medium。也別忘了在 Instagram 上追蹤我,我會定期以簡單的方式分享 UX設計與產品管理的相關工具與技巧。

--

--

--

--

Great article. Valuable insights on the matter of design management and very practical.

I myself tried to build design system three times in 2 different teams and the results were all a mixture of success and failure.

A design system is difficult to build and nearly impossible to maintain properly especially when you are dealing with complex customer facing products in a company with multiple stakeholders.

The amount of time and energy it take is just not worth it and it at best can be treated as a hi-fi mockup tool.

However, the process of making the design system does bring about learnings and does synthesize design ideology and logics within the team.

Maybe thinking holistically about the design, having reoccurring retrospect, documenting the proper structure and UI state are where the value truly lies in Design System.

--

--

特別想討論一下「對設計師需求愈來愈高,甚至沒有產品經理」的這個趨勢。

我前幾週也看到一篇文章在討論這個問題,好像是個印度的產品設計師。他做了一個簡單的調查,發現自己身邊的很多設計師的職責範圍也跨到產品經理的部分了。

我現在的工作模式也是沒有產品經理,設計師負責全部的東西。

我自己感覺雖然這樣需要負責的事情多了,但似乎更合理一些,因為設計師才有最大的誘因與足夠的能力去產出一個好的產品。

我想如果公司的產品本身不需要太多對於市場的理解,也沒有太多資源分配的問題的話,也許真的不用產品經理帶領產品團隊,只需要設計經理統管設計師,然後顧更多設計師、研究員去負責更細的產品Feature就好。不知道這會不會變成一個趨勢呢。

--

--

Hi there, thanks for the nice article!

However I think group has its place to stay.

It allows more intuitive control over the elements, for example, you don't have to worry about dragging an element out of the frame it belongs to. Also it is a pain in the ass when there's frames in frames in frames.

Besides, personally I think the resizing issue you mentioned is over-rated because we would have dedicated frames/variations for different width to demonstrate the behavior.

I agree that when there's extra time or the elements are going to be massively reused, making everything in frame is best practice, I do that as well. But groups are more handy in the process and not using it altogether may create more problem than it solves.

--

--