最近給自己兩個習慣,一個是上班前半小時看些國際或商業新聞,把自己抽離資訊的環境。因為不是本科出身,所以好多資訊科技的東西對我來說都是新的,但發現技術追久了,自己腦袋會變鈍,而且思考很容易變得技術本位。

/

比如說,當我從商業週刊裡得知唐鳳的「數位疫苗護照平台」要用PWA製作時,其實我心裡蠻疑惑的,畢竟PWA本身在底層技術上有很多限制,跟工程師討論也認為這不會是混合開發的首選,Flutter或React Native可能會是更好的選擇。

/

但當我回頭從商業面來檢視「疫苗護照」這個客戶目的時,卻不免覺得:的確,以裝置相容性來說,這種可被安裝的Web APP客戶留存度高,也就是民眾把這個平台留在手機裡比較簡單、且不占空間(許多APP的Lite版本就是如此)、而且開發維護成本也少、功能有最基本的資料傳輸跟推播功能,也是夠用了。

(欸我沒有在背書哦,花多少公帑就讓我們看下去…)

/

商業上要做到甚麼程度對客戶來說才叫夠用,而不是盲目使用最好的技術,真的很吃經驗,適時放下工程端或設計端的盡善盡美,客戶需要的其實沒有這麼複雜。

/

客戶說,想要在庭院裡為孩子架一座鞦韆,設計師設計了歐式的庭園鞦韆;工程師按照人體工學規劃最省力的鞦韆;誰知道父母想的是傳統公園的鐵鍊鞦韆;又怎麼知道孩子想要的只是一條粗繩綁著大輪胎的鞦韆。

Photo by Myles Tan on Unsplash

/

弔詭的是要能做出這樣剛剛好的決策之前,還是得先了解許多技術的東西,想辦法在培養工程思維的同時不落下商業思維、並且不忘記人性。盡信書不如無書,能解決事情的技術方法很多,但能擊出甜蜜點的關鍵永遠在人身上。

/

所以我給自己的第二個習慣就是多主動開口了解人。放輕鬆、不要怕受傷、保持開放心態、盡情體驗,反正人生就一次嘛!(笑

--

--

成為UX/UI設計師一年半後,因為公司人力調動,我成了主要與客戶溝通的PM、並繼續著UX/UI的工作。從需求洽談、釐清問題、競品分析、資訊架構,到wireframe製作、介面設計,交給工程師開發後,還得進行專案進程的控管、開發後的測試、以及交付驗收,比一條龍還一條龍(笑

在與客戶有了更直接的接觸後,真的更深刻體會到身為乙方公司的難處,以及設計師與PM的工作內容及核心能力的差異,如果你也是從UX/UI設計師跨足PM,我想這邊文章多少能幫助你一些😉

Photo by Redd on Unsplash

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

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

畢竟身為第一線處理客戶需求的人,在報價固定、資源、時程有限的狀況下,必須精準地拿捏功能與範圍,而不是被客戶予取予求。

道理看似簡單,但人在江湖,大部分的客戶需求,並不像線上課程舉例的那樣單純,更多的是參雜各方的情緒與壓力:捍衛己見的、固執的、各懷鬼胎想凹功能的(純UX研究可能比較沒這種狀況,因為受訪者大多是出於自願)

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

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

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

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

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

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

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

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

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

再來是成為PM後,有次網頁的區塊間有一條奇妙的白線,請工程師H處理,他卻堅持白線無法修改,我跟工程師H說一定是div margin或padding的問題,請他檢查,H依然不願意修改,最後我只好請他開啟網頁檢查讓我來修改。果然!被我找到多餘的程式碼,修一下就解決了。(事情傳開後,工程師H居然被其他工程師當面恥笑「你居然被PM發現程式碼問題!」)

最近一次是在做主機轉移的時候,我們提供給客戶的檔案出現亂碼,當時我請工程師H檢查一下編碼設定,誰知道原來工程師H在早年的專案中,並沒有做好編碼佈局,才導致現在要解決亂碼的話要逐筆調整。而這份技術債,工程師H自然又是不願意還了,但我仍堅持,即使要花時間,也應該要幫客戶處理好,跟工程師H曉以大義了一番,最後還是在其他工程師圍剿後,才終於妥協整理出一份沒有問題的檔案給我。

或許是我運氣好,遇到的這位工程師工作態度不佳,但我還是要提醒新人PM,不見得所有工程師都願意跟團隊一起為專案的最佳解努力。

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

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

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

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

當時我手上是一個工業協會的官方網站跟APP翻新整合專案,在所有利害關係人皆到場的線上會議中,表面上「協會總經理」是決定官網及APP功能走向的主要人物,而他提出的願景跟大方向,與會的協會秘書跟其他召集人也都一致贊同沒有異議,原以為這次的專案目標能快速聚焦,沒想到會後,秘書與軟體部召集人對功能的設計卻出現了歧見。

其實已協會的組織架構來說,真正執行協會大小事的是秘書,召集人則是在數位化的數據管理上必須跟總經理交代,兩人對其中一項「會員標籤功能」(可以想像是幫會員進行類似市場區隔的分類)有非常不同的看法。

召集人認為貼標籤屬於內部管理事宜,需要的標籤名稱與貼標的動作都應該由協會(秘書)進行,而秘書則認為,標籤的歸類應該讓協進會的會員自己決定,自己既不知道每個會員廠商的詳細屬性,也不願再負擔更多工作。

一方面是積極的軟體部召集人,另一邊則是擁有簽約生殺大權的秘書(你沒看錯,搞了半天總經理根本不管這事),兩人互不相讓,在來回致電協調下,好不容易在召集人願意分擔秘書管理貼標的工作下,雙方才達成了協議,但這齣程咬金也讓專案硬生生拖了近一個禮拜的時間,才決定好程式架構的走向。

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

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

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

如果覺得這篇文章不錯,歡迎Follow、拍手或分享給朋友們!

長按拍手 1~10次 代表還不錯,有學到新東西;

長按拍手 10~20次 代表這篇文章剛好幫助到你/妳,我會很開心的!

長按拍手 20次以上 代表想看更多「Kait | 從UX/UI設計師到PM」的故事!

--

--

上一篇介紹了申請iOS開發者帳號(Developer Account)&鄧白氏(DUNS)的流程,這次為了兌現文中的承諾,來介紹Google Play 開發者帳號流程(笑)

一樣,如有解釋錯誤或疏漏還請鄉親不吝指教~

第一步:申請Google帳號

第二步:於Android手機開啟兩步驟驗證機制

第三步:建立開發者帳戶

第四步:付款完成申請

前往Google建立帳號頁面申請新的Google帳號,若公司已有Google帳號,則可跳過此步驟。

畫面取自Google建立帳戶頁面
  1. 於Android手機點選Google,登入剛剛申請的帳號。
  2. 點擊帳號大頭貼後,點擊「管理你的Google帳戶」
  3. 點擊「安全性」,下拉頁面,點擊「兩步驟驗證」
  4. 於彈出視窗點擊「開始使用」並依照官方步驟開啟驗證

--

--

最近工作上需要協助客戶申請開發者帳號,研究了好一陣子,發現網路上的資料不是短缺、就是年代久遠。

這篇文章綜合實際教學經驗,以2021年實際跑完流程的案例為範本,整理出申請iOS開發者帳號(Developer Account)&鄧白氏(DUNS)的完整步驟給大家參考,Google開發者帳號的申請步驟會另外寫一篇文介紹 :)

如有解釋錯誤或疏漏還請鄉親不吝指教~

第一步:申請APPLE ID

第二步:於APPLE手機開啟雙重認證

第三步:申請鄧白氏認證 (DUNS)

第四步:申請成為開發者帳號 (Developer Account)

第五步:付款完成申請

第一步:申請APPLE ID

前往 Apple帳號申請畫面 申請 Apple ID,若公司已有帳號可略過此流程。

  • 姓名、出生日等:建議填寫「老闆、公司負責人或秘書、經理」等「穩定的授權管理人」資料為佳。
  • Apple ID:以「公司會持續使用的電子信箱」作為帳號為佳
  • 電話號碼:需為「可隨時接通的真實門號」,將用於進行身份驗證。

送出資料驗證,完成申請。

畫面擷取自Apple帳號申請頁面

第二步:於APPLE手機開啟雙重認證

於「公務手機登入」剛申請好的Apple ID,並確保公司人員未來能隨時接收驗證碼,提供給資訊公司進行遠端登入設定。

--

--

嗨我是Kait,在台中一家數位轉型公司擔任UX/UI設計師,遠距上班三天至今,除了大里便當伯就在家附近,讓我有種莫名的危機感之外,客戶突然急件委託要做 #遠端打卡APP 這件事,也令我泛起了 #Designer_can_help! 的使命感,今天就來跟大家簡單分享一下遠端打卡APP的設計歷程~

需求陳述:業主要我們開發一套遠端打卡APP取代感應打卡機,讓公司龐大的出缺勤紀錄不會因為遠距上班而中斷。

1.系統只需紀錄員工上下班打卡就好,經詢問不需要計算中途休息時間

2.不須要求經緯度與拍攝自拍照(經調查,國外打卡APP多有這兩種功能)

3.感應打卡機有固定格式,需配合格式進行資料拋轉。

初版:以感應打卡機為靈感

身為上班,每天趕在8點29分59秒之前快手抽卡感應的經驗,大家應該都有吧(笑),身為打卡系統的使用者,「分秒必爭」是打卡時的情緒也是直覺。所以設計時,我將時間定義為主要資訊,詳細呈現至日/時/分/秒的地步。

時間詳細到顯示時/分/秒

為了對原有資料庫進行資料拋接,打卡資料必須以多對一的方式對應實體感應卡的員工編號。因此初次使用時APP會要求使用者進行工號綁定,綁定時提示框會顯示對應的員工姓名,防止綁定錯誤。

--

--

嗨我是Kait,目前在中小企業的大本營-台中-擔任UX/UI設計師,公司主要承接中小企業的數位轉型專案。工作至今,手上輾轉了不少案子,心中也不斷思索著「數位轉型的本質到底是什麼?」同樣是量身開發一套ERP或APP,為什麼有些企業不久後就能成功導入系統?有些卻在開發上線不久就荒廢不用?

這篇文章不想告訴你網路上都查得到的陳腔濫調,而是綜合這一年來的實務經驗,歸納出數位轉型的3大地雷,希望能減少大家在轉型路上走的歪路。

讓我們開始吧!

地雷一:不清楚轉型目的,把轉型當破壞式創新

「嗯?企業不知道轉型目的,那為什麼要做數位轉型?」天真的我也曾經以為,上門的客戶都會帶著明確的需求來詢問,但以這一年多的經驗來說,一開口就說要做APP的企業不在少數,然而進一步問起確切開發需求,對方卻又支唔其詞,這是由於很多企業對於數位轉型是一項「漸進式的過程」並沒有概念,想靠「數位」一步登天的業主太多,但知道自己要「轉什麼」的老闆大概不到一半。

不論是大企業或是中小企業,都必需走過「數位化」>「數位優化」>「數位轉型」這三個步驟。

千萬別小看「數位化」,數位化涉及到兩個核心問題:「企業該搜集什麼數據」以及「企業要如何利用這些數據」,這不僅與企業轉型的目的息息相關,也是規劃系統架構的依據,有了數據才能談公司的流程優化、成本降低,也就達成第二階段「數位優化」,拉開與其他企業的差距,挖掘更敏捷的新商業模式後,才算達成「數位轉型」。

「沒有從數據觀察到改進之處,哪來的轉型成功?」Photo by the blowup on Unsplash

數位轉型不是破壞式創新,那些老牌企業令人耳目一新的「數位化新商業模式」,也都是經過數位化、數據採集、數據分析所得的結果。

不過值得注意的是,先大規模搜集海量數據,再從中分析企業轉型方向這種「以因為果」的方法,比較適合財力雄厚的大企業,台灣中小企業,不論在資金或體裁上,比較適合「以終為始」漸進式數位轉型,也就呼應到前面說的,要先知道企業目標在哪裡,才著手開發相應的數位工具進行轉型。

地雷二:把數位轉型當專案管理,而非一場策略議題

搞清楚「轉型目的」還不夠,如果企業老闆只把轉型當作「專案」看待,也將導致轉型難以成功。

以專案經驗來看,許多老闆覺得自己只要決定大方向就好,詳細部分就交給「窗口」來處理。在中小企業,這個被老闆指派的「窗口」常常還有自己的事務要忙,分身乏術之外,還可能沒老闆懂公司的發展願景,何談去決定一間公司的轉型事宜?若不是本身對數位轉型已有一定的概念,窗口對達成目標中途該設的小型檢核點常常摸不著頭緒。

--

--

嗨,我是Kait,一個領域跨很大的UX/UI設計師,目前工作滿七個月,在總經理的賞(ㄩㄥˇ)識(ㄑㄧˋ)下兼任「PM」一職,雖然樂意,但對於專案管理仍然是戰戰兢兢,不過充滿興趣! 這次參加的活動是由「UXUI台中聚」所舉辦的案例分享會,講者是曾任Mozilla的User Experience Researcher — Ricky。他從自身經歷出發,分享如何擬定研究架構並找到深層的使用者洞察,特別是進行跨文化研究時所需要得準備與心態。以下是自己內化過後的心得整理,不完全代表講者原意唷:) 我們進入主題吧! Ⅰ、首先,搞清楚研究目的 在進行任何使用者研究前,必須先確認你的「研究目的」是什麼。同樣都是「跨文化研究」,可以聚焦在「新市場開發」的洞察,也可以是探討「使用者經驗」上的差異,釐清好方向,團隊在進行研究時才不至於過於發散。 ⅠⅠ、釐清文化的元素、差異、特性 文化」是由許多構面所形成的,從最表層的「語言、信仰、風俗」,到深度的「態度、學習模式、實踐方式」都是研究時我們應該留意的地方。從不同文化的「差異」,你可以找到產品設計的「切入點」,如果再深究這些「差異」的「獨特性」,就能進一步為產品打造出「甜蜜點」。而以上的思考,都必須留意對設計造成的交互影響。

【心得】UXUI跨文化使用者研究 如何從不同國家的生活習慣 找到產品設計切入點?
【心得】UXUI跨文化使用者研究 如何從不同國家的生活習慣 找到產品設計切入點?

嗨,我是Kait,一個領域跨很大的UX/UI設計師,目前工作滿七個月,在總經理的賞(ㄩㄥˇ)識(ㄑㄧˋ)下兼任「PM」一職,雖然樂意,但對於專案管理仍然是戰戰兢兢,不過充滿興趣!

Photo by UX Indonesia on Unsplash

這次參加的活動是由「UXUI台中聚」所舉辦的案例分享會,講者是曾任Mozilla的User Experience Researcher — Ricky。他從自身經歷出發,分享如何擬定研究架構並找到深層的使用者洞察,特別是進行跨文化研究時所需要得準備與心態。以下是自己內化過後的心得整理,不完全代表講者原意唷:)

我們進入主題吧!

Ⅰ、首先,搞清楚研究目的

在進行任何使用者研究前,必須先確認你的「研究目的」是什麼。同樣都是「跨文化研究」,可以聚焦在「新市場開發」的洞察,也可以是探討「使用者經驗」上的差異,釐清好方向,團隊在進行研究時才不至於過於發散。

ⅠⅠ、釐清文化的元素、差異、特性

文化」是由許多構面所形成的,從最表層的「語言、信仰、風俗」,到深度的「態度、學習模式、實踐方式」都是研究時我們應該留意的地方。從不同文化的「差異」,你可以找到產品設計的「切入點」,如果再深究這些「差異」的「獨特性」,就能進一步為產品打造出「甜蜜點」。而以上的思考,都必須留意對設計造成的交互影響。

這裡Ricky舉了個有趣的例子,他在東南亞做調查時,發現印尼攤販上販賣有許多小包裝的商品,一問之下才發現當地人領的是「日薪」,基本上是當天拿多少薪資就買多少民生用品,所以連洗髮乳都有販售小包裝!但也因為收入不穩的關係,可能面臨了今天有沐浴乳洗澡,但明天卻得用清水洗的窘境。

甚至,連網路也是15Mb左右,小單位逐日購買。

所以對當地人來說,用自己的網路開Facebook是一件很掙扎的事情,萬一第一則動態就是「影片」(還貼心的自動播放),今天的“扣打”就用完了,也不知道有沒有多餘的錢再買一張流量卡。因此,APP的 Lite(精簡) 功能應運而生,只顯示文字動態的設計,不但符合當地人流量不多的使用習慣,相對較小的APP檔案大小,也適應當地人手機容量普遍不大的環境(大部分手機容量為8GB)。

我認為這種觀察方法不限於「跨文化需求分析」,也適用於對任何「特定族群」的觀察。

ⅠⅠⅠ、從微觀到宏觀、從宏觀到微觀

--

--

Kait | 關於從UX/UI設計師成為PM

Kait | 關於從UX/UI設計師成為PM

“Make it simple, but significant.” Kait here, from UX/UI Designer to PM. Practice coding recently.