UX 指導方針¶
這部分的文件是提供給有意提昇 pip 使用者體驗的協力廠商，其中包含 pip 的文件。
什麼是使用者導向設計？¶
使用者導向設計 (UCD) 或以人為本的設計 (HCD) 是一種反覆的流程，設計決策是由了解使用者及其需求而來的。用來描述這類工作的術語有很多；在本文件我們將使用「使用者體驗 (UX) 研究與設計」。
對於 pip 這個專案，UX 研究與設計可以拿來
深入瞭解 pip 的使用者、他們使用 pip 的環境以及他們面臨的挑戰
回報設計關於 pip 的新功能或既有功能，這樣 pip 就能更易於使用和更易於存取。這可能包含改善 pip 的輸出（含錯誤訊息）、控制方式（例如指令和旗號），以及文件
協助 pip 開發團隊根據使用者的需求而優先考慮功能需求
在高層級方面，UX 研究與設計流程涵蓋了
設計，它針對所做的研究提出解決方案。UX 研究與設計以反覆的方式進行，設計建議或原型經由使用者測試來確認它們在滿足使用者需求方面是否有效用。通常，有必要完成多個研究、設計和確認的循環，才能找出有效用的解決方案
如需瞭解這個流程如何應用於 pip 專案的更多資訊，請參閱 研究結果。
另請參閱
為 pip 進行研究¶
使用者研究可以拿來回答幾種類型的問題
瞭解一般性的環境 — 例如，人們如何使用 pip？pip 在什麼不同的環境和脈絡中使用？
更廣義地瞭解使用者 — 例如，誰在使用 pip？他們通常擁有多少經驗？他們如何學習使用 pip？pip 使用者之間是否有任何共通特性？pip 使用者的需求有多麼多元？
評估特定需求或挑戰 – 例如，pip 使用者如何遇到特定問題？什麼時候會遇到？pip 使用者是否定期遇到此問題？新功能將如何解決此問題？
在研究過程中，與使用者互動以收集意見回饋，並將他們的回饋納入決策，非常重要。
來自使用者的意見回饋，對開源專案而言如同程式碼貢獻一樣寶貴；最終使用者可能還沒有準備好提交拉取請求或直接對程式碼進行修改，但他們的回饋有助於塑造 pip 的優先順序和方向。
與開源專案使用者互動的方式有很多種，有時來自社群成員的意見回饋可能會令人不知所措！提供一個結構，例如調查或訪談，可以更容易地收集和理解回饋。關於如何與使用者互動，以下是一些範例
調查 – 針對特定問題、廣泛的社群背景和理解，非常適合有針對性的回饋
訪談 – 針對深入對話，以了解或探索某個主題，非常適合
測試 – 針對評估問題或驗證設計構想，非常適合
開放問題佇列 (例如 GitHub 問題) 和支援票證系統 – 了解常見挑戰的絕佳資料來源
論壇或討論工具 – 了解常見挑戰，或讓更廣泛的社群參與公開討論的絕佳資料來源
研討會和活動 – 進行輕量級的訪談或針對特定功能進行測試的絕佳機會
在執行 2020 年 pip UX 研究 時，我們發現調查和訪談都是與 pip 使用者互動的極有用工具。以下是關於 pip 的一些一般準則和具體建議。
調查¶
調查非常適合收集廣泛且大規模的意見回饋，例如，更深入地瞭解 pip 的整體使用者社群，或針對特定問題取得有針對性的回饋。
調查也可以用於早期的新工具版本，取得原地的回饋，例如，在指令行中提示使用者，如果他們正在使用某個功能的 beta 版本，或向使用者收集關於文件頁面的回饋。
以 2020 年為例，pip UX 團隊發布了多份調查，以瞭解 pip 和 pip 的使用者。這包括
瞭解「誰在使用 pip」
收集關於 pip 文件的回饋
收集關於 pip 2020 年相依性解決方案的 beta 版本回饋
詢問使用者，關於 pip 2020 年相依性解決方案的特定部分，應該如何表現
2020 年發布的所有調查及其結果的完整清單，可以在此找到。
設計調查¶
設計調查時，重要的是先確定您想要了解的內容。把它寫成研究結果/索引問題，這會很有用。範例 pip 研究結果/索引問題 可以在這裡找到。
如果您發現您的主題很大，或您有許多研究結果/索引問題，請考慮發布好幾份獨立的調查，因為過長的調查有反應率低/輟離率高的風險。
以下簡要說明建立 pip 調查的方法
-
介紹您的調查
說明進行這份調查的動機，或（針對 pip 行為的調查）以情況設定場景。 -
設計您的問題
-
試做您的調查並根據回饋修改
這可以非常簡單，只要與 1 到 2 個人分享，看看是否合理即可。 -
決定您要在哪裡進行宣傳活動
確定您想要收到誰的回應，以及您應該在哪裡張貼調查。是否有社群成員或團體可以協助您接觸更多人？
- 是否需要將調查翻譯成其他語言，以接觸更廣泛的社群？
- 您有辦法補償人們的時間嗎？
- 參與者是否希望被感謝為貢獻者？
-
發布並推廣您的調查
請參閱 調查和訪談宣傳活動 以取得基於 2020 年執行的 UX 研究結果/索引進行 pip 宣傳活動的建議。
調查案例研究¶
上述過程是在 2020 年執行，當時我們想要確定 pip 是否應安裝有衝突相依項的套件。
首先，我們介紹調查的目的，以及一個情況
接下來，我們提出一個封閉式問題以確定使用者的喜好
接下來，我們使用開放式問題驗證回應
之後，我們又進一步詢問了有關解決方法、語法和行為偏好的問題。
最後，我們詢問調查參與者個人相關資訊，包括他們擁有多少 Python 經驗，以及他們使用 Python 於哪些方面。這是為了找出不同類型的 Python 使用者是否對問題有不同的回答。
這項調查與 pip 團隊分享，並進行了數次改進，才會透過各種不同的外展管道發布和推廣。
總共收到 415 份回覆，並具有明確結果，幫助我們對此功能的後續步驟提出明確的建議。
分析調查結果¶
調查特別適用於快速了解來自較大量受訪者的趨勢。如果您設計問題得宜，那麼您應該可以輕鬆彙整資料並提出以下此類陳述：X% 的 受訪者 表示 選項 B 是 最佳 選項。
根據回覆進行脈絡化¶
請務必記住，您的調查回覆會受到您進行外展活動的方式所影響，因此除非您確定回覆您的調查的人具代表性，那麼您需要根據參與者對結果進行脈絡化。在您的調查回覆中，查看使用者的不同面向或使用者社群的回覆是否有所不同，將有助於您瞭解差異，例如：
根據經驗等級 - 回覆是否因經驗等級而有所不同？例如，較新或較資淺的使用者是否有不同的回覆、需求或挑戰？
根據背景/脈絡 - 回覆是否因背景或脈絡而有所不同？例如，企業脈絡中的使用者回覆是否與愛好者/獨立使用者相類似？資料分析師的回覆是否與軟體工程師相類似？
回覆數量是否足夠？¶
取決於情況！在像這樣的研究中，這是一個難以回答的問題 - 傳統統計會建議「足夠」的數量取決於您需要這項調查所代表的總體人口。在 UX 研究中，答案通常會趨向於回覆層級的變化，因此這與資料中的訊號和趨勢比較有關。
如果您發現資料中沒有模式，可能表示您的問題不夠清楚或提供了太多選項，或者可能表示您需要接觸更多人。
另請參閱
訪談¶
訪談是深入瞭解使用者、以便深入討論或探索某個主題的絕佳方式。訪談不同於問卷調查，並非了解整體模式的絕佳方式，因為受時間所限，很難接觸到大量使用者。以大會和活動為中心進行規劃，藉此以較為非正式的環境與大量使用者建立聯繫，可能特別有用。
設計訪談¶
和問卷調查一樣，在你開始之前，確定你想了解什麼很重要。
訪談通常使用腳本來進行，藉由提供一些結構，有助訪談順利進行。不過，如果對話朝有趣的或有見解方向進行，即時偏離「腳本」也沒關係。
以下是針對「pip」執行訪談的簡要指南
-
撰寫腳本
這應該包含一份引言，為受訪者說明訪談的背景，說明訪談的主題、你（或觀察者）將如何做筆記，訪談將進行多久，他們的意見回饋將如何使用（和分享），以及你想分享的任何其他重點。
接著，設計你的問題。限制問題數量，以便有足夠時間涵蓋要點，且訪談不會進行太久。如同問卷調查，一個好的經驗法則是，關於使用者經驗層級提出的問題為 2-3 個，以及他們使用 Python/pip 的目的，加上關於特定主題的 3-4 個問題。
有 四種不同類型的訪談問題-
描述性的 — 此類型的問題可以為你提供具體、詳細的故事和說明。它也可以幫助你的受訪者「進入」訪談，重新唤起他們相關的經驗和記憶。例如
- 請告訴我曾經如何…
- 請告訴我第一次如何…
- 請告訴我最後一次如何…
- 請告訴我最糟/最棒的一次如何…
- 請告訴我如何…
-
省思性的 — 這些問題讓受訪者回顧並更深入探討他們的經驗。協助受訪者省思是你訪談的核心所在。不用急，給他們大量空間整理他們的思緒。
- 你如何看待…
- 你對…有何感想
- 你為何會做…
- 你為何會認為…
- 當…發生時，產生了什麼影響？
- 隨著時間推移，...如何改變？
-
澄清 — 這種類型的問題提供受訪者機會，可以針對重點多加說明。技巧性的澄清問題也能讓你悄悄引導受訪者，讓他們說出你覺得最有趣且最相關的部分。
- 當你說…，你的意思是什麼？
- 換句話說，你是說…
- 聽起來你說的像是 [... ]。我說得對嗎？
- 你可以再告訴我更多關於那件事嗎？
-
探索 — 這些問題是邀請受訪者，針對自己的情況進行創意思考，而最適合在面試的最後提出。不過要小心 — 來自單一人的建議，鮮少會成為你的設計問題的答案，而且你需要清楚地告訴他們，你現在只是在收集想法。
- 你會如何改變…
- 如果…會發生什麼事？
- 如果你擁有一根魔法棒…
-
描述性的 — 此類型的問題可以為你提供具體、詳細的故事和說明。它也可以幫助你的受訪者「進入」訪談，重新唤起他們相關的經驗和記憶。例如
- 和 1-2 人進行試驗面試，並根據他們的回饋進行修改
-
決定如何進行面試
- 你想確定從哪些人那邊取得意見？你需要在哪裡張貼訊息，才能聯絡到人來進行面試？是否有社群成員或社群可以協助你找到特定的人員？
- 是否需要將面試翻譯成其他語言，才能接觸到更多社群人員或特定社群？
- 人員要如何報名參加你的面試？
- 您有辦法補償人們的時間嗎？
- 參與者是否希望被感謝為貢獻者？
-
開始進行宣傳活動！
請參閱調查和面試宣傳，以取得有關如何根據 2020 年進行的使用者體驗研究，來推廣 pip 的建議。
以下是與使用者討論 pip 文件時所使用的範例使用者面試腳本
前言
首先，感謝你撥出時間，並且持續參與。
這次面試的目的是，希望更深入了解 Python 社群成員如何認知並使用 pip 文件
面試時間大約 30 分鐘。如果你有任何不理解的問題，請要求我重複或重新說明。如果你沒有好的答案，可以告訴我跳過。
我會做筆記。這些筆記會分享在 GitHub 或 pip 文件中，但我們會移除任何可識別的資料，以保護你的匿名性。
請誠實回答 — 你的回饋，可以幫助我們讓 pip 變更好。對於你所說的任何話，我都不会介意 :)
（選擇性）你是否介意我錄製這場訪談？
序言
可以告訴我你如何使用 Python 嗎？
你使用 pip 多久了？
解決問題
可以告訴我你使用 pip 時曾經遇到的問題嗎？
發生什麼事了？
你做了什麼？
你去了哪裡？
你如何解決你的問題？
請前往 https://pip.dev.org.tw/en/stable/
你曾經使用過這個文件嗎？
在 1-10 分的評分中，它有多有用？
為什麼？
是否有哪些你在使用的專案，希望我們在考慮如何改善 pip 文件時可以參考看看？
是什麼因素讓此文件佳/有用途？
結論
pip 團隊可以做一件事來協助使用者排除 pip 問題是什麼？
您有任何問題嗎？
多少次訪談才足夠？¶
這取決於您正在討論的問題的複雜程度，以及您是否覺得從執行過的訪談中獲得足夠的見解。這也取決於您是否從各種類型的人身上獲得見解。例如，您可能希望在聽取專家和初學者 pip 使用者的意見後才停止訪談。
通常，執行幾次訪談就能發現很多問題，足以向團隊提出建議。
分析訪談資料¶
正式的訪談分析通常使用一個名為「編碼」的程序，其中多位研究人員檢閱訪談記錄並根據已開發的編碼系統或類型學標示不同的陳述或評論，以與研究保持一致。這是一個非常棒的作法，也很棒地確保研究人員的偏見考量在程序中，但大多數團隊沒有人員編制或資源執行此作法。
取而代之的是，許多小型團隊使用輕鬆的程序，將訪談陳述捕捉為主題，例：需求或挑戰周遭的特定主題或問題領域。訪談也是引述的絕佳來源，引述有助於提供為何某些事情很重要的範例，或是在什麼時候/如何對使用者產生影響。
訪談分析常使用便利貼，您可以在上面寫下引述、問題或發現，然後將便利貼移至可貼上標籤或分類為主題的群組。遠端時，可使用各式各樣的工具協助，例如 Miro 或 Mural 等數位便利貼工具，或是 Trello、Wekan 或 Cryptpad 等看板工具，也可以只使用文字文件或試算表，並使用清單與類別。在每次訪談結束時，使用 去識別檢討工作表 可能會有幫助，您可以在忘記特定訪談中的主題之前，快速捕捉見解與主題。
另請參閱
調查與訪談外展¶
以下列出 pip 團隊在 2020 年執行研究時使用的一系列外展平台。有些比其他平台成功
建議：使用者體驗研究小組¶
作為 2020 UX 研究 的一部分，我們公佈了一個表格，要求人們加入研究小組並定期收到有關問卷調查和訪談機會的消息。這現在是一個 使用者可以註冊的郵寄清單，除了廣泛的公眾外展活動，還會持續使用。
建議：Twitter¶
我們發現 Twitter 是與 Python 社群互動和推動參與 UX 研究的非常有效的平台。我們建議
建議：特定興趣小組¶
我們透過 PyLadies 社群的 Slack 頻道 與其互動，以促進更多使用 pip 的女性參與，因為我們發現透過其他頻道很難接觸到該群體
建議：研討會社群¶
由於 2020 年全球大流行，我們無法像我們希望的那樣透過 PyCon（或其他區域研討會）與使用者互動。但是，我們仍然推薦這個頻道作為與大量有興趣的人快速深入互動的方法。
值得探索：在 pip 的 “說明” 命令中新增提示/路徑¶
我們沒有機會探索這個機會，但這個想法是在 2020 年 12 月與 Pypa 維護人員的研討會中提出的，而且可能是吸引使用者並幫助他們找到機會做出貢獻的好方法。
不建議：論壇 (Discourse 等)¶
我們使用 discuss.python.org 數次發布到 包裝論壇，詢問包裝維護人員對 pip 功能的看法。不幸的是，這不如我們預期的那麼有成效，只有很少的回應。我們發現透過 Twitter 與包裝維護人員互動更有效率。
在 Reddit 上發布問卷調查也沒有想像中那麼有用。如果發布這項調查或呼籲參與研究的使用者在 Reddit 上沒有顯著的信用，那麼發布過程本身就會充滿挑戰。總之，相對於其他推廣管道，我們從 Reddit 獲得的問卷調查或訪談參與度不高。
使用介面設計¶
許多人將「使用者介面」這個詞與網站或應用程式聯想在一起，但重要的是要記住，命令列介面 (CLI) 也是一種使用者介面，而且應享有與圖形使用者介面相同的設計考量。
pip 的設計考量包括
設計 pip 的輸入 - 建立依指令分組功能的最佳方式，以及如何命名這些指令，以便使用者理解
撰寫 pip 的輸出 - 建立 pip 對指令的回應方式，以及它提供給使用者的資訊。這包括撰寫成功和錯誤訊息。
提供補充資料 - 例如，幫助使用者了解 pip 操作的文件
設計原則 / 可用性探索規則¶
有許多互動設計原則，可協助設計人員設計絕佳的體驗。Nielsen Norman 的使用介面設計的 10 項可用性探索規則是很好的起點。以下是這些原則如何應用到 pip 的一些方式
系統狀態的可見性：確保所有指令產生明確的回饋，與使用者相關 - 但不要用過多資訊讓使用者負擔太重（請參閱「美學與極簡設計」）
一致性和標準：撰寫介面時，應力求與 Python 封裝生態系統的其他部分保持一致，並（在可能的情況下）採用其他 CLI 工具中的熟悉模式
美學與極簡設計：去除 CLI 輸出中的雜訊，以確保使用者可以找到最重要的資訊
協助使用者辨識、診斷和復原錯誤：清楚標示和說明錯誤：發生了什麼事、原因為何，以及使用者可以採取哪些措施來嘗試修正錯誤。連結到需要提供詳細說明的文件。
說明和文件：提供脈絡說明，並確保文件以任務為導向
其他資源¶
設計工具¶
設計過程中經常使用的工具包括角色設定和指南，還有流程圖、原型製作和測試，以及建立流程圖或模型。
角色設定¶
想要更深入瞭解角色設定以及在開源專案中使用它們的資訊，來自 Simply Secure 的這項資源可能會有所幫助。
角色扮演是可能使用你的工具之人的抽象概念或原型。它通常採用快速描繪的形式，包含像姓名、年齡範圍、職稱等，足以讓你對此人的身分有些概念。你可以將此資訊寫到角色扮演範本中，並將其作為資源分享給你的開放原始碼社群，請參閱來自 GitLab UX 團隊的範例。
角色扮演特別有助於依特定使用者特定需求之優先順序來紮實功能設計的基礎。這有助於在設計過程中提供實用的限制，讓你得以專注於工作，而不是試圖建立適用於所有使用者的瑞士刀解決方案。
2020 年，pip UX 團隊為 pip 專案制定了下列角色扮演
Python 軟體使用者
Python 軟體開發者
Python 套件維護員
關於 pip 角色扮演建立方式，以及如何將其應用到未來 pip UX 工作的深入說明，請參閱此處。
原型¶
在任何 UX 專案中，使用實際使用者製作原型並測試介面非常重要。這會為團隊提供回饋迴路，並確定提供給最終使用者的解決方案能滿足他們的需求。
製作 CLI 原型可能具有挑戰性。請參閱使用 cli-output 製作快速 CLI 原型以取得建議。
文案編寫風格指南¶
基於 pip 的介面是文字，因此使用清晰一致的語言特別重要。
下列文案編寫風格指南對 pip 團隊來說可能很有用
Firefox
Heroku CLI（特別針對 Heroku 的 CLI 工具）
一般資源¶
Heroku 對其 CLI 工具設計的說明 (影片記錄)