ひな 分享
1 years ago @Edit 1 years ago
About AAPD Campaign & Side Project
Only plurker's friends can respond
latest #17
ひな
1 years ago
2023.7.16
結束了side project 的 kick off meeting,老實說有點傷心。一直以為我在工作上多少學到了一些專案管理跟產品發想的技能,但發現有更多更厲害的人比我還要有想法。再者,雖然自願當組長,但在會議上一直沒有組長的風範,當然在這次會議上嘗試了提出話題、總結、記錄follow up 事項,但也感受到組員的質疑。
ひな
1 years ago
- 時間拖太長:有位香港組員不太會講中文,除了講的慢以外,還常常我們有了結論又提出詢問。
☞ 解決方式:限制每個人發言時間、多訓練思考,填補無人發言的時間、多留意agenda,如果發現時間拖太久還在同一個議題就要趕緊進入結論。

- 定義時程不明確:非常嚴重的錯誤,我竟然會說「週二確定主題再討論後續時程、這週平日完成」這樣的話。
☞ 解決方式:定義明確時程、避免模糊不清的字眼,專案這種東西一定會有異動,但身為專案管理一定要先定義好時程規劃。
ひな
1 years ago
2023.7.18
第二次會議,本次的目標是確認產品類型,聚焦化功能以便統整MVP範疇。這次的會議比較用跟去發言跟統整,但中間還是碰到了許多令我信心受到打擊、值得反省的事情:
- 發言拖太長:本來預定半小時結束會議,但又拖了一個半小時才結束。前面各自講產品想法時,雖然有預定3分鐘的限制,但包含我有三個人講超過了,覺得身為組長這是很不應該的事情。再者,第二位成員超時時,我也不敢開麥打斷,是另一位成員E開麥提醒的,
☞解決方式:可以學學E的應對方式,「不好意思,因為我們有限時三分鐘,麻煩請在一分鐘內發表完」
立即下載
ひな
1 years ago
- 產品發想太廣泛:我提案的產品發行中包含太多功能了,又要提供白噪音、書籍、podcast等資源,又要提供資訊預約服務、又要提供日記功能,並不是不能包山包海,而是完全沒有意識到我們的專案時程緊湊、資源有限、更沒有實際「同理」焦慮病患真正所需,他們真的需要這些玲瑯滿目的內容嗎?會不會給了太多反而最後不使用?

- 無同理心:承接上面,在會議上提了兩個想法都被成員打槍(心裡受挫...)。一為功能太多,焦慮患者已經夠煩了不希望再接觸這麼多資訊;二為將情緒分數化,焦慮患者看到很低的分數反而更失落。
ひな
1 years ago
☞ 反省:正所謂Google UX課程所提及的 Empathy,任何產品都需要深入瞭解使用者所需。經過團隊裡兩位曾經患有相關疾病的成員的回饋、還有成員E研究中親自訪談輔導老師的分享,我才驚覺自己完全沒有站在用戶角度出發,而是看到Behance上很美的作品就拿來當參考,東抓一些西抓一些來拼湊。
其實跟現在接觸的產品很類似,韓國PO一直沒有深入研究台灣市場,導致產品始終優化一些小地方等等,明明站在旁觀者的角度檢視韓國,自己真的在規劃產品時卻忽略了重要的部分!
ひな
1 years ago
不過還是要說,發現自己其實不討厭與組員、同事一起討論產品規格的!尤其當大家一開始的想法很發散,到最後聚焦到重點結論時,我想這就是團隊合作跟做產品開心的地方,果然還是想往產品領域繼續邁進!
附上與成員討論的一些過程
https://images.plurk.com/54KSEcLJDnNYMIqSpEIFL8.jpg https://images.plurk.com/7FXqTuSWyeNiWWk2gTN1nr.jpg https://images.plurk.com/2fLG5xGnXwa96jTRDkptTO.jpg
ひな
1 years ago
2023.7.18
課程解說課時slido上出現很多不滿的言論,該怎麼說,一方面覺得利用匿名給予批評滿無恥的,一方面也不能怪他們,畢竟面對面或真名溝通時,我們往往會顧及多方而只給予正面的評價。

就我而言,我覺得實戰營有好有壞。
- 壞的地方在於,學生真的好多(雖然也間接讓我意識到比我努力的人很多),聊天室一大堆的留言看的我很煩,且導師有限的情況下,無法給予太多照顧;另外,正課其實也就8小時,8小時要學理論、component 、varient 、varieble 、auto layout、工程交付、mockup等等,雖然濃縮到都是精華,但相對也代表每堂課的負擔很重、短時間內要吸收很多東西、每個東西都無法垂直細講等等
ひな
1 years ago
好的地方在於,我終於用figma做出一些東西來了XD 不過我覺得最近心態一直還沒有改成on的模式,拖延症、焦慮、疲乏感加重,導致不專心、沒有持續練習、沒有積極利用資源、沒有去迭代舊的設計。並且一直以我是全職為藉口逃避,真心想回到高中那個什麼都要問到會的自己。但這真的是我自己的問題😢
撇除硬實力,我覺得實戰營給我最多的,其實是我意識到自己其實很自大,雖然學經歷沒有我好,但思考、設計、心態比我的人有太多太多了。還有就是Simon跟Kat真的是人生導師,間接給我好多啟發,不管是學習心態、人生規劃等等,這些無形的東西其實拉了我一大把,很感謝世界上還有一些無私的人一直分享著,好希望30過後的我也能成為一位好mentor
ひな
1 years ago
2023.7.16
第三次會議,這次會議氛圍好非常多!甚至有說有笑,可能最近沒什麼動力,對什麼都提不起勁,這次討論起有想法的產品才慢慢找回那種快樂的感覺,雖然討論到半夜,但是對於產品越來越有共識、越來越能想像作品的產出就很開心,果然還是想往產品這條路前進~
本次反省:
- 在公司學到東西終於發揮作用了!我自己覺得在工作上我做的蠻好的地方在於研究planner的wiki時會思考到更多邏輯問題,這點在這次mvp整理以及對於wireframe的回饋非常有幫助,能夠指出更多更深入的待評估項目。另外也發現自己做的作品都看不出盲點,別人的wireframe 可以點出一堆feedback XD
☞解決方式:果然規劃設計這種東西還是要多跟一些人對焦才能知道自己沒有考慮到哪些細部內容
ひな
1 years ago
- 我發現我自己對於一個功能會有更多的發想,有些發想可能是必要的,但有些發想可能漸漸遠離產品核心目標。ex.推出獎牌解鎖,但忽略我們的用戶是有輕微焦慮,只希望透過我們的app進行簡易的情緒紀錄,那這個功能真的是需要的嗎?
☞解決方式:每隔一個階段或有一個功能發想就要去review是否扣合產品核心目標
ひな
1 years ago
2023.7.27
第四次會議,沒想到又是一次討論到00:30的一天...我甚至連作業都還沒做完QQ
值得開心的地方在於大家對於身為組長的我感覺越來越信任了!雖然在這次的專案中,組長兼任的職責並沒有想像中大,但很開心組員們都有認真聆聽我的建議並且大部分我的提議都有被採納或認同~
相對的身為組長也是要做一些其他犧牲?例如
- 詢問誰要去做presentation時沒有人願意只好自己接下,但我是不介意,反正就是多練練present。
- 當組員提出需要幫忙時需要主動cue其他組員詢問是否可以幫忙...真是蠻尷尬的。
其實我也有點怕我做的不夠多QQ 但是進入實戰營後才發現我的技能真的不如人,很怕我做一些很難的元件毀了整個作品哈哈哈
ひな
1 years ago
2023.7.28
Design Review
因為沒有人自願上去發表,身為組長只好自己扛下了XD 但其實我本來就想去發表,一方面加強自己發表的能力、一方面是我總覺得自己做的還不夠,設計元件的部分因為對軟體操作超級不熟,很怕被我搞砸,希望我還算做的來的地方可以多幫忙。以下是這次的反省:

- 關於成員s的設計。其實成員s原本並非負責元件設計,但因為元件設計負責人連續四天不在,加上有蠻多東西需要變動,所以才請s幫忙。沒想到s將原本該組員的設計都改了,以個人主觀美感而言,其實我比較喜歡原本的設計,但畢竟設計非邏輯,我也不好去批評。不過比較令我不愉快的,是我點出了好幾個“邏輯”類的問題,例如篩選器的篩選邏輯,我講出來後他持續表達沉默不願修改,甚至我也將其他app的邏輯呈現貼上去了...
ひな
1 years ago
隔天成員z提出了新的設計,我覺得比s的好很多,因此我們緊急之下改了畫面,畢竟一小時後就要review,很難融合細調。改完後也在群組通知s,沒想到s回覆「欸你把我的設計全改掉了==」後續也用文字表達如果要改他設計的話,那就不要叫他幫忙,不然浪費時間。成員z連忙出來道歉,我也幫忙說跟z討論後,發現s的設計邏輯有些需要修改的地方,所以先用z的,若s之後方便,都可以review後開會,一起討論出最佳的設計方案。
☞反省:其實身為設計人,我也知道設計被整個換掉很沒禮貌,設計沒有對錯,所以更難去表達他的設計美不美、好不好。在溝通這一塊,要怎麼樣讓大家都得到一個共識,也是我想去學習的。(後來Nelly有講到一點我覺得還不錯,當這個 app放到商店上,真的能吸引用戶去下載嗎?
ひな
1 years ago
- review 前,我整理flow的時候才發現好多問題跟細部要調整的地方(之後觀察其他組也發現我們的設計被點出最多待改進的地方就是元件不統一、沒對齊etc )。為了效率,我私下密了成員z詢問是否能快速過整體flow,後來兩個人一起整理也發現效率快很多,發現找到頻率對、小團體討論真的很重要...,間接也證明為何公司討論常常覺得浪費時間又沒結論xdd

- 本次重點design review!整理好內容後我基本上只剩下1.5小時左右練習發表,因為發表時間只有8分鐘,我真的是邊講邊刪內容,剩下真的需要講的內容,然後不停的練速度,在發表前,我的時間其實一直超時大概10-20秒,超級怕現場超時... 想著我上去時絕對不要有冗詞綴字,給我好好照大綱講:)
ひな
1 years ago
以發表這塊而言,這次review 做的很好且收到稱讚的地方在於
1. 時間掌握不錯,7:52秒左右完成,聽到班長這樣講,想著其他組應該是有超時...
2. Kat 大力稱讚的地方,就是我在發表一開始有向同步我們這組的進度跟脈絡,這是他目前遇到唯一一組有做到的。其實這塊我超級不確定要不要講,因為一開始練習的時候足足花了1分半,最後濃縮到1分鐘,很怕班長跟組員會不會認為我幹嘛花時間在這塊上面,結果竟然被大力稱讚,真的是我沒想到的QQ 也因為這點,組員們後續都在群組鼓勵我,感受到他們對我的信任度提升,真的很開心,看來在公司被小主管訓練寫background 真的有用:)
ひな
1 years ago
待改進之處:
1. 其實不只班長直接點出,我自己也覺得我聲音超級抖xd 畢竟是對不認識的人發表,更不知道我講的內容在業界而言到底是不是正確的,很怕對方一邊聽一邊翻白眼(?)總之對於台風這部分,從小開始一直是我的障礙啊...
https://images.plurk.com/5S0Jo07ghRczHV5VGbjzP3.jpg
ひな
1 years ago
補充Kat在結束前有詢問我們這組有正職設計師嗎?我回覆沒有,他說如果我們都是初學者,能提供這麼完整的設計很厲害,這點對我們來說真的是強心劑!(雖然我半夜偷偷去看其他組的內容覺得也都很厲害...)
感謝我的組員中有幾個是真心想做好的,也都很配合,也希望然後我自己做個人專案時,可以針對軟體元件設計方面更成熟!
back to top