別管微軟HAI guidelines，你看過連學習單都幫你準備好的Google People+AI Guidebook了嗎？
超級獨家：心智圖介紹六大章節10+子原則
人工智慧正夯，產品設計屆乃至於人機互動學門都開始思考，如何應對產品裡永遠都在學習的黑箱演算法。微軟於2018年SIGCHI發表了人智互動準則(Guidelines for Human-AI Interactions)，Google也不遑多讓在今年2019年上線了人類與人工智慧手冊(P+AI Guidebook)，共計六章，每章的末段還有worksheets可供參考。
你可能會問，等等AI不是很好用很夢幻嗎，為什麼需推出設計指南與手冊？
使用者依據對產品的心智模型(mental models)進行互動，但因為AI產品將因演算法不斷學習而不段改變，所以用固定的心智模型去理解同一個產品就不可避免地會產生失誤。「如何面對產品的不確定性」也因此成為AI-assisted產品設計師首要的難題。
本文會先用PAI官方順序粗略介紹六章節內容；接著將會用我理解的方式，比較細緻地討論PAI在開發中可能可以怎麼用。
官方章節排序
- User Needs+ Defining Success 使用者需求與定義成功
- Data Collection + Evaluation 資料搜集與評估
- Mental Models 心智模型
- Explainability + Trust 可解釋性與信任
- Feedback + Control 回饋與控制
- Errors + Graceful Failure 優雅的失誤與錯誤
前兩章先講做產品的首要任務是要「使用者需求與產品目標」，再來便是該「如何將產品需求轉化為AI需要的data」。剩下的四章主題變比較分散，第4章心智模型章如何介紹AI給使用者跟解釋AI系統會隨時間改變，第5章與第6章則討論該如何讓使用者控制系統與給予回饋；何謂系統失誤應如何妥善的引導使用者面對系統錯誤。
雖然初看覺得很合理，但看過第二階層的標題和內文後某些地方，對於某些安排有些困惑，像是有些地方有重複或是安排的順序不合理之類的。所以我又看了第二次，這次我不太管官方的章節安排，試圖重新把內容重新排列，以便自己的理解。下一章節就是我在二次閱讀後所make sense後的PAI理解方式，歡迎大家一起討論。但我真的要再度重申這是我自已的解釋方法，請大家take it with a grain of salt。
ys流的PAI釋義
我覺得PAI裡面給予的指示建議可以分為兩部分：
- 基礎建議(fundamental suggestions)，亦即產品的基礎建設，自己覺得偏需要和RD一起討論牽涉到技術端的設計。
- 使用者使用流程中會遇到的事件(event-based suggestions)，像是如果遭遇錯誤怎麼辦等等。
AI產品基礎建設建議
- 了解AI的強項，以決定是否適用AI、用哪種AI跟哪時候用AI
AI的強項弱點與適用時機在第一章的Find the intersection of user needs & AI strengths 和Assess automation vs. augmentation。這邊我覺得還蠻有趣的是PAI有提到使用AI時也要評估precision和recall的問題，和初步思考如何應對使用AI帶來的壞處。 - 確定使用AI後，將需求轉化成Data Need並留心資料來源與品質
這部分都寫在第2章，因為AI的強大來自於於他學期的資料，所以這部分資料的品質與來源是近年來非常重要的議題。需要保護資料來源的隱私與安全不在話下，但同時應該注意「資料的公平性」(Commit to fairness)。資料雖然應該反應真實世界，不過如果少數族群的資料太過稀缺，也會造成該部分的運算結果不慎理想，像是以白人為主的辨識系統可能就會一直覺得亞裔人士沒有張開眼睛之類的。除了以上比較難處理的問題話，第2章也對開發團隊該如何取得資料，與該如何將資料設計對未來幫忙label資料的人更友善提出不少建議。 - 讓產品更容易被理解與信任
AI系統因為會隨時演進，PAI建議可以提供「解釋」或是「信心」來協助使用者理解系統的決策。（過往的研究也的確指出面對智慧系統提供解釋有助提升使用者對該系統的信任）不論是選用解釋和信心來輔助使用者，都需要RD的協助，因為解釋需要一起討論該解釋內容為何即如何生成；用信心的話則需討論應什麼標準來訂立信心，該信心又該如何生成。因為牽涉到比較基礎的技術，所以我自己將第3章的Explainability + Trust一併納入產品的基礎要求。PAI有提供不同類型的解釋與信心供大家挑選，例如數字或高中低方式誠信信心，有興趣的務必親洽官網（欸。
AI產品事件導向建議
- 協助建立合理的心智模型
如前述「AI產品會不斷變化」這一點是人智互動的核心（至少我是這樣認為），所以第三章Mental Models，PAI便建議產品應該要讓使用者對產品的有正確的期待(set expectations for adaptations)。首先要先了解使用者現有的心智模型(Identify existing mental models)，進而能提供適合的輔助。在使用者剛接觸AI輔助產品(onboard in stages)時，應該要明確說明產品的界線，可以做什麼與無法達成什麼，讓使用者有合理的期待。 - 鼓勵使用者給予回饋以精進系統
Feedback相關散見於第3章Mental Models和第5章的Feedback+Control。核心概念就是「整體產品設計應該要讓使用者能夠和系統一起共生(Plan for co-learning)」。AI輔助產品需要使用者的回饋才能從中學習，所以PAI也鼓勵明確的告訴使用者需要他們提供回饋的原因和好處，並讓使用者有感於提供提供回饋的好處。PAI列出了四種不同的誘因（物質回饋、抽象回饋、利他主義、既有動一），並分析各自的利弊。
系統所要求的的回饋也需要規劃的對AI模型有幫助，要不然使用者的回饋完全就是給心酸啊，PAI將回饋區分為explict和implicit兩種，前者為使用者主動提供，後者為系統自動收集使用者被動提供的資料。若遇使用前者則需注意回饋的設計跟他可以怎麼幫助系統，後者的話，則需要再次將使用者的信任和隱私納入考量，因為很多時候使用者是不會注意自己已經分享了什麼樣的資料的。 - 給予使用者一定的控制
了解人們何時想要有掌控權（使用者享受該活動、使用者偏好為該活動福澤、任高稱本、較難溝通的個人偏好）；了解何時願意讓系統自動化（使用者無法做該活動、不安全或無聊的活動）。
提供切換(Allowing for opting out)與編輯的可能(Provide edibility)。前者是尊重使用者的決定，如果已詳細介紹功能了但是使用者決定不要，這時候就應該尊重而不是強迫，強摘的果子不甜（？）；後者則是使用者的習慣是會改變的，所以應該保留一定的彈性，讓使用者未來能夠自訂偏好。 - 如何處理錯誤
這部分可以分成三部分(1)定義錯誤(2)找出錯誤來源和(3)如何處理錯誤。在直譯是錯誤與優雅的失敗的第6章，PAI首先定義什麼是錯誤(error)*，在非AI系統中有“user errors”和“system errors”，前者是系統設計者認為使用者做錯了才導致錯誤，後者是使用者認為系統設計錯了才衍生錯誤。PAI認為在AI系統會有第三種錯誤即“context errors”。Context errors是指「系統生成的結果在使用者所在的情境不合理」的情形。因為這樣的錯誤和使用者所處的情境有關，PAI建議系統設計師去理解AI用了哪些signal來猜測使用情境，透過調整訓練資料解決context errors。**
PAI列出四種方法如何找出失誤來源（identifying errors sources）類似看過往訓練出現過的錯誤或是否是使用者的輸入有問題等等。因為比較細碎，建議直接到PAI官網上查看。至於關於怎麼處理錯誤，PAI提供兩種策略，一是讓錯誤成為使用者提供回饋的時機；二則是把掌控權還給使用者，讓他自己決定這時候結果應該如何。但前面的章節也有提到，當系統對於結果不確定或無法自動完成活動時，基礎設定應該以不仰賴AI為主，所以系統失靈時使用者仍有機會大成目的。PAI提到一個有趣的點，他提醒設計者雖然可以向使用者解釋系統為何失誤，但必須注意如果解釋得太過詳盡可能導致不肖使用者找到系統的漏洞，像是你明確告訴使用者哪些會被歸到spam mail以後大家就會繞過那些規則然後系統就會失靈。
* PAI其實沒有明確定義“failure”，只有在第6章討論「使用者的心智模型會影響他們是否認定一個系統行為是錯誤」時提到「例如一個60%準確率的推薦系統到底是成功還是失敗，會受使用者的不同和系統設立的目的影響」。(For example, a recommendations system that’s useful 60% of the time could be seen as a failure or a success, depending on the user and the purpose of the system.) 我猜會這樣區分是因為錯誤不見的是失敗，如果使用者理解特定錯誤的發生他不見得會認為這個產品是失敗的。既然會有分歧的結果，所以就必須把他們分開。但沒定義的確比較麻煩。
**“Situations when the product output doesn’t make sense in the user’s current context. Often, this output is perceived as irrelevant by the user.” 摘自官方的名詞定義集。但老實說我覺得不論是failure或error定義都沒有很明確，所以閱讀時只是籠統的用「系統出錯」去理解。
小結
PAI講的事情很多，我這篇字數…也是不少。如果有時間，非常建議自己看過一次PAI。但如果要我選一個最主要的takeaway那就是…
「AI產品會隨時間變化，請思考如何讓使用者和系統一起成長」。
只要有這個問題意識，就可以理解大部分PAI的出發點（說決大部分是因為trust和explanability無法被涵蓋，但這不代表他們不重要，老實說我覺得這兩個更重要，因為使用者必須要信賴該系統，產品才能夠持久。畢竟當你開始對工具產生不信賴感，如果有機會應該就會想要替換他吧）。理解PAI出發點後，剩下的也就簡單了，PAI雖然給出複數種建議，但那也是因為AI被使用在不只一種場合，產品的特性use cases都不同，自然會有不同的答案。這也是為什麼我會說只要記住上面的問題，並且design along it，應該便是一個好的開始了。
但以上僅適用在決定要用AI之後，如果還沒導入AI，首要任務應該是認真的思考，我們的系統到底需不需要AI，是為了更好的體驗還是只是為了賣點或是譁眾取寵。如果只是出於啊大家都在用我們也要用的心態，而且你也有意識的話，我…也是無話可說了呢（欸。
最後，希望ys流PAI釋義 還算合理，然後能讓你閱讀正版的更快進入狀況。我看得很開心也寫得很開心，我們下次見（但下次是誰要提AI guideline我真的就不曉得了，Amazon嗎）！
附件：可編輯心智圖xmind檔案下載
因為我覺得官網很花，概念與概念間的階層不太清楚，不容易一望即知，所以在閱讀的過程中用xmind做了心智圖，方便閱讀。如果想進一步看非大標比較細緻的補充資料，歡迎使用xmind下載連結。如果對HAI有興趣，也可以參考當時有參加PAI制定Microsoft Sr. UX Design Lead 陳翰申的演講分享。
噢對了，似乎最後一段都要放一些call to action叫大家拍手或追蹤什麼的。但我覺得我寫的文章略小眾，所以大家自由心證不強求。
- YS Chiang ：可以看到我中文與英文的發文，基本上會發一些小眾設計相關的文章，分析產品（例如痞客邦）或介紹工具（例如這一篇）什麼的。
- trialnerr0r ：矢志讓他成為一個英文publication，基本上就是參加研討會或是我看了什麼文章的心得摘要，最近多半是人工智慧法治相關文章。
