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 的設計流程
本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知。