Kawamata Satoshi 是日本的設計師，在日本知名電機製造商的設計部門磨練後，進入 Goodpatch 擔任產品設計師。這位日本設計師時常從定性 (質性) 訪談以及觀察進行深度學習，且擅長發現問題以及分析。在完整的軟體開發流程中，從概念架構到設計製作皆不陌生。在 Goodpatch 的設計委託案部門經歷過數個專案後，於 2016 年轉到自家產品開發部門，且首度經手的產品 Balto 即獲得 Good Design 獎殊榮。
服務的起源
我們認為任何產品的發展都是由發現「問題」開始的。就 Balto 而言，當初想要開發的動機是「在實裝後的 APP 上給予 Feedback 的程序很麻煩」，這是個常被忽略的小問題，然而身為一個設計師，是否能運用想像力解決或延伸其他可能性呢？
在設計 Balto 的過程中，我用了以下 3 個方法：
觀察
身為設計師，找出課題時可先從觀察身邊各種細節開始。首先，我是透過觀察周圍與身邊同為設計師同事的工作模式，看他們「一天當中」的「作業」行程，並把上班到下班的作業內容依時間排列出來，然後再把他們的工作動力用曲線表示，來呈現各個不同階段心情的起伏。
從圖表中我們可以看到，在「檢視實際安裝後的產品並給予回饋」時工作動力是大幅下滑的，顯示設計師們在從事這段作業是心情通常較低迷。
從觀察的過程中定義出「大家對於在實裝後的 APP 上給予 Feedback 這個流程感到無趣而麻煩」，從截圖、圈選、傳到 Slack 再與工程師溝通，任何一步皆非常耗時且繁鎖。為了解決這個問題，設計師們簡易的發想後，立刻請工程師做了一個簡易的 Prototype （其實在 Goodpatch 裡面一直都有這樣「先試試看」的文化存在），經過內部試用後發現它實在相當方便，便決定全心投入這個工具的開發，以上就是 Balto 誕生的原點。
當我們從觀察開始延伸出新的 idea 且發現問題時，我們常常會困惑這個問題會不會流於主觀？這樣的課題在市場上是否存在？又是否有去解決的價值？其實只要迅速地在 Prototype 上確認，就能檢驗產品的價值與蓋念是否合適，且也更容易定義產品。
了解使用者潛在的需求
為了解這些潛在需求，我們必須先實施深度的訪談（Depth interview）。我所使用的方法在富士通學習到的的 Aim Interview。Aim Interview 的特點在於把焦點放在「認識人」上面，藉此引導出「潛意識」並透過「6眼模式」來捕捉人的特徵。基本上就是一對一進行一大約90分鐘的訪談。
所謂的「潛意識」是指：雖然平時不太知道怎麼用言語表達，但只要努力就能夠具體表述的或感覺上的事情，可能是本人沒注意到的問題以及生活中鼓勵引起他動力的事物，換句話說就是「真心話」。使用者內心深處的潛意識是可以透過不斷地詢問發生的狀況與感受，來將問題引導出來。
所謂的「6 眼模式」是由三條不同的軸線組成，而軸線的兩端分別是相反的兩種不同觀點，將一個人的習慣和發言傾向，帶出他的人格來分成六種不同觀點（如圖）。
「未來觀點」與「過去觀點」指的是過去的經驗以及對未來的展望。有些使用者在訪談時特別喜歡談論自己對未來的展望，此時可以透過詢問他過去的經驗來問出該使用者潛在的，自己平時沒有意識到觀點的感受。
「邏輯觀點」與「感覺觀點」指的是是個人在表達自己感受的時候，習慣從邏輯觀點出發還是感情觀點出發。若該使用者習慣針對既成的事實去做描述，則可以從感情面去詢問當他遇到該狀況時的心理狀態。
「個人觀點」與「集團觀點」是指有些使用者喜歡用自己的角度出發去回答問題，而針對習慣從自己觀點表述的試用者，可以嘗試詢問他當時周圍第三者的人是怎麼看該狀況，促使該使用者從第三者的觀點來回答問題。
訪談總體的架構會切成三個不同的大方向：「過去」、「現在」與「未來」。我們從過去的經驗中可以構思出未來的期待的狀態，未來的想像則給予現在的行動方向，現在行動的動力則是建構在我們過去的經驗。
在訪談最初，先詢問受訪者比較容易闡述的「現在」的狀況，接下來問問看「過去」所發生過的事件，最後以「現在」和「過去」為鑑詢問出使用者對「未來」的想法。在這三個步驟中又以詢問未來狀況最為重要，從使用者對未來的描述，可看出他期待的部分。
上圖是當時所使用的訪談表單，我個人都會根據當時的情況調整表單，總共有100張不同形式的表單。訪談過程中盡量讓受訪者自然的描述，從各種觀點丟出問題給受訪者，通常話題也會自然而然往各種方向去延伸。全程訪談約 90 分鐘，結束後我們將會將受訪者敘述的內容寫成文字並整理在表單上。這個作業非常耗時，但對於深入了解使用者是不可或缺的過程。而寫出來的內容我們會再以 Customer journey map 和Persona 這類較簡潔明瞭的方法來表示。
在 Balto 發想時期，我們也訪談了工程師，大部分工程師們在完成 App 實裝後，都非常希望得到更多的 Feedback。因為他們也希望能將一個經過千錘百鍊的產品自信的送使用者手上。
得到這樣的受訪者訊息後，我判斷他的潛在需求其實是「希望可以將搜集到的 Feedback 應用到產品的改善」，而不是單純只是想要搜集很多 Feedback 而已，這是在這訪談中得到最大的啟發（insight）。透過使用者訪談去理解需求對產品的方向設定是相當重要的。
走到這個階段，我們會遇到的問題是「如何將訪談的結果轉化為自己的語言，來傳達給團隊其他人知道」。而我們發現，讓所有跟產品企劃相關的團隊成員（包括工程師和 PM，）一起參與訪談，直接傾聽使用者們的聲音．團隊會更有共識。
運用想像力延伸解釋
如同前文所述，雖然我們從訪談中得到了潛在需求，但是我們需要透過跳躍性地思考、延伸自己的想像，來猜測「會不會是這個意思?」。訪談者希望將搜集到的 Feedback 應用到產品改善中，但在之前，我們需要先搜集到大量的 Feedback。那要怎麼做才能搜集到大量的回饋呢？要解決大家不喜歡給予回饋的問題，我們運用想像力來延伸解釋，思考如何營造出可以搜集到很多 Feedback 的氛圍。
這裡我們訂出三個方針：
- 製作一個可以輕鬆傳達 Feedback 的體驗
- 做一個可以持續收集更多回饋的器皿
- 讓 Feedback 的過程可以變得更正向積極，用 Feedback 來提升團隊的士氣。
上圖是在構思 Balto 的世界觀時所畫的插畫，在 Balto 這個平台上站著的是各種不同職業的人（設計師、工程師、 PM），另外也有很多截圖與影片立著，大家在上面熱烈地討論著，這正是 Balto 想傳達的理念。
而 Balto 以一個團隊領袖的姿態，帶著這個積極改善產品的團隊前進，將產品的品質往更好的方向。
Balto 帶出了「Design Feedback Communication」這個概念，讓大家的 Feedback 不再僅針對抓蟲和錯誤指正，而是有更多討論主題，包括稱讚或設計和體驗上的回饋等。在這步，產品大致的概念也有譜了，但還是會遇到提案無法得到上層認同的問題，不過若早期將決策者拉近溝通的圈子裡，其實就能更順利地前進。
最終的成品：Balto
Balto 是以 “一個動作” 就能簡單地將螢幕截圖或影片回饋給工程師的服務，大多使用於 Beta App 的內部測試時。簡單來說，就是一個傳送意見回饋的溝通平台。除了讓開發團隊進行意見回饋時的溝通更加順暢，並快速提升 App 的改善週期之外，Balto 希望能讓設計的 Feedback 變得更加積極與正面。從 Balto 的介面設計中便可以看出，它增加了設計者與回饋者之間的互動性，使 Feedback 的流程不再枯燥，提升團隊成員們給予 Feedback 的意願。
Balto 的功能說明
- 以一個動作便能拍攝影片、螢幕截圖
拍攝螢幕截圖之外，還能拍攝6秒鐘長度的影片。
包括互動與畫面變化等動態地方也可給予意見回饋。
- 以形狀區域選擇螢幕截圖
可用圓形、方形、箭頭3種形狀區域選擇所拍攝之螢幕截圖。形狀有5種顏色。
- 附上評語簡單的意見回饋
可在所拍攝的螢幕截圖與影片中，附上評語進行意見回饋。
已寄送的意見回饋，可由Balto行動式APP、Balto網頁管理畫面進行確認。
- 統一管理意見回饋
可於BaltoWeb管理畫面進行意見回饋一覽。
意見回饋以APP為單位相連。
Balto以秉持著「正向地去提升產品的品質」這個信念開發而來，我們也稱 Balto 為「支援開發者的工具」，希望藉由這個工具能讓各位開發者的開發過程不再生硬。
結語
身為設計師，我認為仔細觀察身邊每件瑣碎的小事，針對平常不會注意到、微不足道的點去做深度思考觀察是非常重要的，培養這樣的觀察能力，透過設計的力量去改善一個一個小缺口，讓大家的工作流程變得更愉快、更流暢有效率其實就是設計師的使命。讓我們一起在這個領域一起開心的工作吧！
從找出問題開始 – Designer’s night @Taiwan
以 Feedback 工具『Balto』的開發流程為案例，整理從發現課題到面談方式、觀察的方法的簡報。
原文由 Goodpatch 投稿提供 – 如何讓 app 的產品回饋更流暢 – Balto 的設計流程
本文章所屬設計大舌頭與作者所有，未經授權，不得轉載！如需轉載，煩請通知。
