身為產品設計師,我從工程師身上學到的產品開發心法

每日 Stand up、Sprint 計畫、回顧會議、迅速迭代

Jasmine Lin
Feb 2 · 8 min read
文章所有圖片來源:Open Doodles from the best Pablo Stanley ❤️

由於我這幾年都是就職於 design agency(設計工作室),我們並沒有很多 in-house (組織內)的工程師資源,唯一的前端工程師人在倫敦,我從來沒機會跟他合作。

因此,我一直以來的對口都是客戶端的工程團隊,將設計檔寄出去之後不一定有辦法實時回饋,如果不在檔案或信件中解釋清楚的話,對方有很大的機率會誤解,所以我交付檔案給工程師的時候都比較慎重、詳盡。

直到幾個月前,我們工作室為了孵育自家產品,招募了兩名工程師,一名後端工程師與一名偏向 UX Engineer 的工程師(對 UX Engineer 有興趣的話請參考好友 Mimin(zuku) 關於 Google UX Engineer 的文章)。

兩位都是從競爭激烈的遊戲產業出身(他們之前在植物大戰殭屍的公司工作),各自都有將近十年的實戰經驗,也曾經管理過工程團隊,所以對於產品開發的理解比我們公司所有人都更熟悉。

最近我也投入自家產品的開發,跟這兩位工程師和一位資深互動設計師組成四人專案小組,發現自己簡直愛翻跟工程師並肩合作了。

導入產品開發流程

由於設計工作室的性質,我們以往都是根據客戶的需求以及時限來推進專案,例如三個月的專案要花兩週完成產品策略、四週完成線框圖之類的決定都在專案一開始就非常清楚,所以我們雖然有設計迭代(從設計圖 A 轉變成設計圖 B),卻沒有很明確的產品功能迭代。

工程師將他們的產品開發流程導入到我們的 workflow 中,幾項簡單的例行事項就讓我們的 workflow 越來越流暢,也讓我學到許多產品開發的眉角。

Daily Stand Up 每日站立會議

工程師很堅持每天都要有十五分鐘到三十分鐘的 stand up meeting,讓每個人概略報告一下自己昨天做了什麼、今天打算做什麼。

站立,而不是坐著,強化了該會議打算簡短且避免浪費時間的想法。站立會議並不是一個解決問題的地方,而是讓一個團隊意識到現在的狀態。如果需要討論,適當部門可以安排另一個更長的會議。(摘自 MBA 智庫百科

一開始我很疑惑為何需要如此堅持每一天都要開會,畢竟有時候設計卡關,可能連續幾天都在做一樣的事情,stand up 的時候反而會感到自己沒什麼能分享的。

後來發現每天 stand up 讓大家永遠有機會可以提出問題,或是分享遇到的困難,比較不會因為偶爾一次的大會而感到有問題太小不該問,或是有問題還等到下次開會的時候才問,那都可能已經太遲了,stand up 能夠幫助團隊迅速注意到癥結點。

Sprint planning 衝刺規劃會議

我們採用 sprint 的方式開發產品,利用 Asana 當作專案管理的工具。工程師提出一種理念是:在每個 sprint 開始時都重新建立一個 Asana board,目標是要在 sprint 結束時將所有卡片消掉,沒消掉的卡片就要在下一次 sprint planning 時決定是否延續此項任務,要不然就做好 documentation(文件紀錄)之後屏棄掉,絕對不存 backlog 在這個 board 裡頭。

另外,在創建任務卡片時也不會一開始就指定負責人,因為設計工作室的接案本質,每個設計師都有可能因為新進的專案而被抽出這個小組、轉移重心,所以最重要的策略就是要讓任務模組化,卡片可以隨時交接,當我重新加入專案時可以將沒有人負責的任務撿起來做。

Retrospective 回顧會議

再來說說我最喜歡的項目 — 回顧會議(Retrospective,簡稱 Retro),在每次 sprint 結束後都會開一次,顧名思義是要回顧這個 sprint 的好與壞,藉此更加精進我們的流程,以下是我們 retro 的架構:

  1. 回顧上次的行動項目(action item)
    根據完成程度幫自己打分數,我們是用笑臉、木然臉跟哭臉當作評分
  2. 做得好的部分
    稱讚大會,將這次 sprint 裡頭運作良好的部分提出來。曾經出現過的讚賞是任務量計畫得剛剛好、工程師跟設計師溝通良好等;也會提到一些比較隨興有趣的,比如說倫敦的工程師當爸爸了、感恩節要到了。
  3. 有待加強的部分
    這大概是最重要的環節,只要專注於點出問題是什麼,避免直接跳到解決方案,以免時間浪費在試圖解決一個問題,卻沒有正視所有問題(這真的超級難,所以我們經常要口頭提醒彼此不要跳到結論)。
  4. 解決方案的行動項目
    將有待加強的部分全數列出之後,選定幾個來想出可能的解決辦法,產生的行動項目要指定給某一個人,避免三個和尚沒水喝的情況。

我很喜歡 retro,因為這跟個人的自我省思很像,每次反省都能讓我們更了解自己、找出問題與解法,進而讓流程越來越進步、順暢。

工作過程中如果感覺自己因為某些流程感到困擾的話,也不會因為跟實際的設計工作無關而一直悶在心裡,retro 時就可以一一點出。

工程師說從來沒人喜歡過 retro,一直說我真是奇怪的人 😂 但除了我認真相信反省能讓團隊變得更好之外,我也認為 retro 做得好的話是個近似於 team building(團隊建立)的環節,讓團隊成員更了解彼此在乎的點。

迅速迭代

最後一項並不是實際方式,而是一種心態,跟設計工作室以往風格不相符的心態。

再一次,因為工作室的接案本質,最終成品往往是送出去之後就沒有機會修改了,而送出去的成品代表著我們工作室的聲譽,如果繳出的品質不夠好,客戶就不會回鍋了,導致我們很多時候對最終設計過於小心翼翼。

一開始我們總是在很後期才跟工程師說設計需求,擔心他們會做許多白工,工程師後來反倒反映說趕快產出各式各樣的原型才比較好進行測試,讓我們親身感受一下我們畫出的流程真的使用起來是什麼感覺。

他們說,在開發產品初期做任何決策時,我們要捫心自問的第一個問題不是「這會成功嗎?」,而是「我們可以從中學到什麼嗎?

開發產品時就不能總是將完美當作目標,而是要以學習、改變為最高目標,不畏失敗,先推出才有真實的數據跟回饋得以學習。

工程師總是鼓勵我們只要產出「夠好」的設計就可以了,我們永遠可以在下一次迭代導入真實的回饋,無論是來自於真實使用者或是團隊外部的回饋,來進行迭代,而不是單純用設計師的臆測與想像中的完美不斷自主迭代。

設計師友善(designer-friendly)的工程師

雖然說比起視覺設計師,我自己在思想上本來就跟工程師比較接近,但這兩位工程師真的是非常設計師友善,從來沒有讓我感覺到設計師與工程師之間常有的緊張關係。

溝通、溝通、溝通

第一次跟 in-house 工程師合作,能夠進行各種現場交談就已經讓我覺得樂勝遠端合作,而且他們又特別強調溝通的必要性,他們不斷灌輸我一個觀念就是「如果被卡住超過 15 分鐘,來找我們」「如果對工程限制有什麼疑慮,來找我們」「如果想講垃圾話,來找我們(欸)」

總之就是設計師有什麼新想法都盡量跟他們說,他們都很願意仔細聆聽設計師的想法,同時也會提出身為工程方的見解,比較偏 UX Engineer 的那位甚至會提供解法,畫出線框圖跟我們溝通。

同時,他們也很尊重設計師的看法,當他們在架構後端的時候,偶爾也會丟出一些問題說「這樣的資料處理方式,好處是 ooo,壞處是 xxx,我覺得這樣做比較符合使用者流程,設計師你們怎麼想?」尊重設計師專業,不會逕行做決定。

合作彈性

對於設計迭代他們也完全接受,因為我們不走瀑布式開發,所以有時候設計師在畫圖的時候,工程師也同時在寫同一個頁面的 code,設計經常在變,導致他們時不時會需要這邊改改、那邊修修,他們完全 OK,我跟另一個設計師常常打趣地說我們完全被寵壞了。

結語

幾個月的合作下來,跟這兩位工程師在私底下也變成好朋友,很常跟他們在 Slack 私訊(額外發現:工程師真的很愛 meme 跟 gif),也偶爾會跟他們出去 happy hour 喝酒聊天,他們也一直說要教我怎麼寫 React(真是太看得起我了)

最近深深感到能夠跟他們認識並合作真的是太幸運了,從他們身上能學到很多在設計師身上學不到的東西,覺得自己對產品圈的知識又多了一些。

如果喜歡這篇文章,請幫我拍手1-10下。
如果喜歡閱讀關於設計師的職場觀察,請幫我拍手10-30下。
如果單純喜歡我的文字,希望看到更多的話,請幫我大力拍手30-50下。
也請記得 Follow Jasmine Lin 或是數位產品設計 Medium 文章平台 As A Product Designer,讓我們與你分享更多好文章 😊更歡迎你在文章底下留言,我很樂意也很期待跟你討論或聊天!

Jasmine Lin

Written by

UX Designer / Information Architect from Taiwan, now living in Seattle.

AAPD — As A Product Designer

AAPD 專注於分享數位產品設計的相關資訊,並且致力在平台上創造更多的交流與互動,我們關注UI設計、UX設計、設計師的個人成長、設計趨勢與產業動態等,希望透過這些知識的傳遞,能夠降低每位設計師成長的過程中所遇到的阻礙。歡迎來信投稿:aapdgo@gmail.com

Jasmine Lin

Written by

UX Designer / Information Architect from Taiwan, now living in Seattle.

AAPD — As A Product Designer

AAPD 專注於分享數位產品設計的相關資訊,並且致力在平台上創造更多的交流與互動,我們關注UI設計、UX設計、設計師的個人成長、設計趨勢與產業動態等,希望透過這些知識的傳遞,能夠降低每位設計師成長的過程中所遇到的阻礙。歡迎來信投稿:aapdgo@gmail.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store