Prott User Meetup in Taipei vol.1

氣候多變的2017開春，2月10日迎接Goodpatch團隊的是一個寒冷的天氣。不過，幸好設計師與關心Prott應用的使用者們熱情不減，仍在準時的時間內抵達位於三創園區的會場。看到現場的空位陸續被坐滿，許多陌生又期待的眼光都讓Prott團隊的心情為之一振，新年度的第一場Prott與用戶間的交流盛會，就在掌聲中展開！

首先，由Prottt創辦團隊Goodpatch在台灣的事業發展經理Stephanie，向我們介紹Prott近期升級的新功能；
包括「畫線搞功能優化」、「改善Sketch Plugin」、「切換組織帳號的UI改善」、「一次拖曳多張畫面圖像」、「Prott viewer for　Android正式上線」，並告知大家Prott已經開始經營繁體中文Change log，讓使用者們能拿到第一手最新的產品更新資訊。

Stephanie也與我們分享了接下來預定的改善方向，將會以「Prototype為中心改善團隊溝通」的大方向，先著手改善Comment功能並強化與其他系統的連結，而現在眾多使用者愛用的畫面流程圖功能也正式升級上線，所有精益求精的努力，都呼應了Prott開發時的核心精神「1000個會議不如一個設計原型」。

原型設計在巷弄｜時間軸科技股份有限公司

第一位分享人Kate向我們說明開發「巷弄」時透過Prott應用的小故事，透過她不藏私的分享，讓人獲益良多；同時也感受到了時間軸科技在產品開發上回歸用戶體驗、滿足用戶需求的體貼與細心。

在優化服務說明之後，緊接著是邀請時間軸科技首席產品設計師Kate Wang王俐絜，分享「巷弄」App在製作過程中，如何利用Prott提升設計流程的效率。Kate表示，「巷弄」開發的動機，就是考量到許多上班族外出吃飯非常花錢，因此希望透過App開發與商家合作，每日販售限量的半價票卷；除了能替使用者省錢，也能達到店家宣傳的效果。

Kate不藏私的告訴我們，決定產品開發後，就要思考以下三個Prototype製作前的提問：
1.TA：Prototype製作好要給誰看？給誰用？
2.Goal：Prototype製作的目的為何？想要達到什麼目標？
舉例說明：消費者市場調查、功能流程確認、Demo測試等。
3.Contents：介面內容該怎麼設計、如何呈現等。

除了創作邏輯上的解說，Kate也直接透過投影片讓我們了解「巷弄」製作時經歷的三種種Prototype類型：

①速度型－鉛筆手繪稿
TA：開發團隊內部使用
使用時機：
・創意階段：UI、功能尚未確認。
・設計階段：開發討論。
・意外階段：新需求出現。
重點：手稿快則手稿先行；軟體操作快則軟體先行。主要依據個人熟練程度，利用手繪可快速跟團隊溝通。

②詳盡型－線框
TA：主管/開發團隊
使用時機：
・創意階段：功能已確認，UI、流程未確認。
・設計階段：流程反覆調整。
重點：流程為主，操作、Flow Map愈詳盡愈好，每項互動與觸發條件要想清楚，愈詳盡可愈快調整Prott，確認操作流程。

③擬真型－Mockups
TA：老闆/業主/開發團隊
使用時機：
①Scrum(敏捷軟體開發)階段：Planning Meeting。
②設計階段：UI、流程已確認
重點：讓客戶得以想像成品，須至少跑過一或二的方式，避免直接擬真製作，不符預期需打掉重練。

Kate表示，Prott帶給他最大的收穫，就是「擬真運用」上的便利性。因為，透過Prott製作出的Prototype呈現，不僅可以讓給予跨部門溝通的夥伴更具體的想像；接近真實的App但不需動用到工程層面的展現方式，既美觀又能具體呈現App成品樣貌。而且在Prott的特質上，優化測試、檢視流程問題的特點，不僅增加易用性，也讓研發團隊更加節省時間與金錢的開發成本。

【Kate的QA】
Q1：講者提到有「反悔」的機會？那在設計過程中可反悔到什麼程度？
A1：舉例來說，目前正在跑Scrum，若有增加新的需求，不會更動現階段的功能，客戶若有需要，就放到下一階段討論。Scrum的好處是敏捷式開發，必須在一開始就要很清楚它的功能。

Q2：線框的部分「巷弄」高達六七十頁，那手繪稿也需要畫到這麼多嗎？
A2：手繪不會，只寫需要知道的畫面與必需功能，線框的目的是強調流程，若客戶與團隊都非常熟悉整個流程，就不需要線框，可從手繪直接跳設計。

Q3：若從手繪階段跳設計，缺少流程階段，是不是因為設計師和工程師是同一角色？
A3：對，「巷弄」和一般App設計比較不同的是，這是我們自家的產品，設計師設計好後有極大的權限可去說服團隊的其他人開發這個功能，但若是一般專門開發App的公司，可能就需要和客戶或廠商討論，那就需要線框的階段，去確認每一階段的功能和流程是否順暢。

讓Feedback也能更正面而有效率｜Goodpatch新產品Balto

「Balto」是Goodpatch的新產品，而這次到場跟大家做介紹的是來自Goodpatch東京本公司的產品設計師Kawamata先生。

Kawamata先生表示，Balto是將設計的Feedback變得更積極正面的回饋溝通平台；目的是將Prott運用在開發階段，讓工程師之間的溝通更為順暢。

雖然Kawamata先生是日本人，但是，相信全世界不分性別種族的工程師，都有一樣的困擾；就是產品研發過程中，設計師無可避免地需要跟工程師討論產品的錯誤，而工程師則是要永無止盡地做修改，整體流程往往讓人覺得既不耐煩，又容易失去熱忱。有時候，當大家為了想避免給予回饋時的尷尬與麻煩時，產品的品質其實就會間接受到影響。。

「Balto」的開發動機，是為了減少回饋流程時所遇到的問題，讓回饋流程更為順暢，藉以提升App整體體驗的品質。Kawamata先生很具體地向大家說明，一般的回饋過程，會透過「截圖」搭配文字說明，並搭配Excel或是Spread Sheet等表單工具來做彙整，有時甚至會從Mail或是Line來搜集各種Feedback，這樣的流程其實會造成修正指令過於零散，容易產生疏忽與誤解，而這對開發工程師來說，是非常挫折且困擾的一件事。

然而，透過Balto的彙整，可以讓Feedback變得更清楚、有對照性，甚至增添幾分遊戲的氛圍，讓回饋的過程變得輕鬆且有趣，不僅能收集到更多的Feedback、有效記錄修正進度，還能幫助團隊給出不只是修正指令，而是正面稱讚的回饋，製造出好的氛圍，間接提升開發效率。

Kawamata先生告訴我們，Balto存在的三大重要方針，都是為了優化工作流程，並且帶動更正向的開發回饋：

Balto重要的3個方針
1.製作一個可以輕鬆傳達回饋的體驗
2.製作一個可以持續收集更多回饋的器皿
3.讓Feedback的過程可以變得更正向積極

而Balto這個產品也在持續的進化當中，在不久的將來預計將會追加以下三項主要功能，降低各位導入的門檻：

1.與GitHub做連結
2.信用卡線上支付功能
3.沒有SDK也能發送

當日，Kawamata先生除了向我們說明開發的動機、操作應用的方法，最引起大家關注與討論的就是Balto的形象概念，一隻鼻子很靈敏的狗兒。Kawamata先生說：「Balto，就是引領團隊的存在。」有部知名動畫《雪地靈犬》，Balto就是裡面擔任領袖的主角；因此，利用「嗅覺靈敏的狗」的形象，賦予Balto靈魂，延伸其「靈敏、擅長發現問題」的特色，在產品開發過程中找出問題、給予回饋，Balto將成為改善產品品質的領袖。

以下，整理摘要幾個問答給讀者參考：

【Kawamata先生的QA】
Q1：在安裝有SDK情況下的App是否可以直接公開上線？
A1：一般轉出需將SDK拿掉，但未來會開發不須使用SDK的版本，便可直接轉出。

Q2：未來是否會開發網頁版？
A2：日本也有人反映，內部也有具體再作討論，將來有機會推出。

Q3：Balto產品概念中所提到把回饋變得正向積極，主要是指什麼部分？
A3：Balto上面除了可以提出產品的問題外，也有讚美與按讚的功能，藉此給開發人員鼓勵，並且會記錄每人提出Feedback的數量，達一定次數會像遊戲一樣右上角的皇冠越來越亮。

Q4：先前有提到重視使用者的經驗，請問是如何挑選出測試時的使用者對象？
A4：當時在進行訪談一開始就有找了小中大各類型的公司的同仁進行共同測試，最後挑選了大概十位左右。

Kawamata先生示範Balto的實際使用流程，大家都非常感興趣；亮眼、清爽的使用介面，確實讓人無法想到這是一個「挑毛病」的回饋平台。

製作VEGERY時的活用方法 | ｜Balto Team Product Manager Nakamura

參加者普遍可能都有有疑慮，Balto在實際的專案上要怎麼樣應用呢？因此，在Kawamata先生介紹完Balto之後，就是Balto的專案經理Nakamura Hiroki先生，來跟我們分享他實際使用Balto優化產品開發流程的體驗。

Nakamura 先生告訴我們，「VEGERY」可以線上訂購新鮮蔬菜的App，主打一小時之內可送達的便利與新鮮特性。一般而言，產品開發設計流程會經過以下四個步驟：

1.搜尋問題
2.Team Building/Concept Making
3.Prototyping
4.改善優化

而Goodpatch接到VEGERY設計委託案時，之所以用到Balto，主要是因為在Prototyping的階段，已經用Prott做了一定程度的流程檢核、改善，當然也有內部回饋確認過，但實際安裝時，往往又會有新的Feedback出現。Nakamura 先生跟大部分的產品經理一樣,
以往都採用Excel或Spread Sheet表單式管理，但瑣碎的資訊非常麻煩，不要說工程師了，
連產品經理自己都常常搞不清楚要修正的項目究竟有什麼。

透過在第三階段的Prototyping時，導入Balto管理整個回饋測試流程，Nakamura先生發現這個產品除了讓惱人的Feedback變得有趣，明確的指令與圖像示範，也幫助了不少不擅長溝通表達的同事，讓整個團隊成員都能清楚的明白對方觀察到的問題所在。

另外，過去在開發各階段所冒出的Feedback十分零散，但是透過Balto可集中管理，一目了然、完整記錄整個產品的優化過程，並且讓修正指令回歸到產品本身，降低開發團隊在彼此傳達上的失誤，都是Balto獨道的特色與價值。

坐無虛席的演講現場，雖然碰到的是台北的真冬低溫的日子，但是聽眾的熱情卻讓現場充滿正面溫暖的氣氛。

Nakamura先生的分享之後，引來了聽眾的興趣與好奇心，相關的QA摘錄如下：

【Nakamura先生的QA】
Q1：請問是否有Bug優先順序管理的功能？
A1：暫時無法決定Feedback問題解決的先後順序，接下來會開發GitHub連結的部分，採用GitHub管理會是比較理想的。Balto的優勢在於提升回饋流程的效率以及搜集設計體驗的Feedback，跟管理Bug和Issue的工具有些不同。

Q2：在截取影片的部分現在是限定6秒，未來是否考慮開發自訂時間的功能呢？
A2：我們也有接收到一些類似的回饋，但目前尚未有這樣的功能，未來有考慮是否和其他公司合作以外掛的方式補足這塊功能。

Q3：工程師是否會因為一直收到Feedback而感到焦慮？
A3：製作前設計師曾詢問開發者的需求，許多開發工程師對於自己做出來的東西其實是很不安，也會擔心是否有問題沒注意到，因此收到Feedback是很開心的。

短短的兩小時分享交流時間，在聽眾熱切的提問下很快邁向尾聲。Goodpatch團隊非常高興看到今日的分享活動不僅出席踴躍，在互動發問上也非常積極，這個令人感到充實且欣慰的午後，在幾位講者無私分享之後，在開心的披薩香之中畫上了句點。

這是在台北的第一場Prott User Meetup，我們希望可以透過這樣的形式將台灣UXUI設計圈的同仁們集合在一起，彼此分享交流設計的know-how，讓大家一起做出更多更好的產品，期許接下來每個月的Prott User Meetup各位都可以來參加！

差點擠不下鏡頭的大合照，感受得到大家對活動與產品的正面肯定！期待不久的將來能再與各位見面，也期待收到更多關於產品服務和交流的回饋！