從UX/UI設計師成為PM,工作內容與核心能力哪裡不一樣?

Photo by Redd on Unsplash

一、 面對客戶修改,PM要踩住底線、善用籌碼

做Designer的時候,常常是透過PM得知客戶反饋,再合作進行修改。那時候覺得,PM好像只需要下指示就好,現在才發現原來每個異動的功能,都可能是PM用盡全力擋下來的最小幅度修改。

所以,身為接案顧問公司的乙方,在前期溝通後擬定的合約就是整個專案的底線。

PM在對客戶溝通時必須拿出原則:範圍內合理的、對使用者來說必要的調整,PM可以選擇協助修正,但那些超出資料庫架構的、屬新流程的,PM最好以「不在合約範圍內」的方式化解掉、或善用「驗收」作為籌碼,收到客戶尾款再另起專案,既不讓原有專案賠錢,又有新的專案收入。

二、PM不能沒有基本程式概念

其實,基本的「程式概念」在當UX/UI Designer的時候就很重要了,不僅是要了解原生、客製元件、還要理解資訊架構與邏輯,才不會設計出工程師做不來的介面或是流程。而PM「不能沒有程式概念」的原因有兩個:

1. 知道客戶需求如何轉化成工程邏輯

有了基本的程式概念,能讓PM在跟客戶溝通時,知道該問些什麼、或是必須婉拒什麼,否則PM很容易淪為工程師與客戶間的傳聲筒。

從保持團隊的生產力的角度切入,讓手下的工程師保持專注在「開發邏輯的心流上」是很重要的,因為每打斷一次工程師,他們都得再花額外的心力回到剛剛的開發邏輯上。身為PM,如果你多懂一些程式,就會知道該問清楚哪些東西,就可以很快跟工程師確定架構走向,也可以先把客戶過於天馬行空的需求在會議中先化解掉,讓專案進行更有效率。

2. 為了不被工程師矇

以前早就聽大家說「PM與工程師是相愛相殺的關係」,從Designer跨PM後真的特別有感觸(笑)

先說好,我很愛我團隊的工程師們!但很不幸的,我也被其中一位工程師矇了不只一次!

我們稱他為工程師H,最早一次是當設計師時,按鈕有肉眼可見的鋸齒邊緣,跟工程師H反應後,對方居然以每台手機解析度不同唐塞,我一想,誒不對啊!我已經照Android dpi分門別類出給你了,怎麼可能有這種事,搬出理論反駁後,H他只好摸摸鼻子將圖片放到正確的dpi中。

職場上喜歡偷懶推託的工程師,都很擅長利用「資訊落差」來晃點別人。如果不會一點程式基礎作為自保或是據以力爭的武器,專案的進行只怕除了「外患」還有「內憂」。

三、 想結案?先處理好「利害關係人」!

能左右客戶需求的因素實在太多了,其中最主要、也最棘手的就是「利害關係人」的處理。

在市面上的課程或講座中,「利害關係人」常常只是一閃而過,我想就是因為情況太多元,很難用隻字片語去解釋。

其實在我們這行,技術都好解決,難的是利害關係人多時,要如何達成專案需求整合,才是考驗PM功力的時候。

結語:都是在處理人,但面向與深度大不同

UX/UI設計師與PM都要理解客戶需求並提出解方,但更多的,PM要處理的是關於人的事情:不論是對外的協調、對內的時程管理,絕對沒有表面上以為的悠閒啊!(笑)他們是專案進行的推手,也是保護團隊的第一道防線,同在這行的朋友們,我們一起加油吧!

--

--

“Make it simple, but significant.” Kait here, a product manager of carbon footprint verification and energy monitoring IoT system.

Love podcasts or audiobooks? Learn on the go with our new app.

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
Kait | 關於成為Product Manager

Kait | 關於成為Product Manager

“Make it simple, but significant.” Kait here, a product manager of carbon footprint verification and energy monitoring IoT system.