diff --git a/findings-report-zh-tw.md b/findings-report-zh-tw.md
new file mode 100644
index 0000000..d223506
--- /dev/null
+++ b/findings-report-zh-tw.md
@@ -0,0 +1,267 @@
+![Cover image for Designers in OSS: Summary of diary studies of designers contributing to OSS illustration of a person with their back to the camera with a laptop and book open in front of them](https://raw.githubusercontent.com/simplysecure/Diary-Studies-Designers-in-OSS/main/images/blog-image-1.jpg)
+
+
+# 1. 在開源軟體中的設計師：開源軟體貢獻設計師日誌研究總結。
+
+2022年，[佛蒙特大學複雜系統中心](https://vermontcomplexsystems.org/partner/OCEAN/awards/) 向 Superbloom 授予了一項 OCEAN 獎助金（開源生態系統與網絡研究獎勵計劃），以調查並為目前正在為開源軟體貢獻的設計師提供機會，讓他們得以在安全的環境中，以匿名且尊重隱私的方式描述他們的經歷。我們能夠為一部分設計師提供津貼，以便他們能記錄[日記研究](https://www.nngroup.com/articles/diary-studies/)中對開源軟體貢獻的相關資訊。
+
+這項短期研究計劃旨在探討一些與開源軟體設計相關的關鍵問題，並填補非代碼貢獻者在開源軟體中的經歷所留下的較大系統性“信息缺口”。由於研究的局限性，所有這些問題都是從設計師自己的角度回答的，因此具有其個人偏見。
+
+* 為開源軟體貢獻設計的設計師通常有哪些經歷？
+
+* 在開源軟體項目中，特別是關於“設計貢獻”方面，哪些條件能讓設計師取得成功？
+
+* 在項目和社區層面，哪些條件可以為設計師創造一種包容感？
+
+* 什麼是設計貢獻？人本設計在開源軟體社區中如何被理解？
+
+* 設計師與開源軟體專案開發者/維護者/社區如何描述“成功”的設計貢獻？
+
+* 設計師如何描述與開源軟體專案開發者/維護者/社區之間的“成功”合作關係？
+
+OCEAN的使命是“研究開源社區如何聚集在一起解決複雜問題”。人本設計的本質是通過以用戶為中心的研究和設計方法來解決問題，這些方法以他們試圖解決問題的工具的各類用戶為中心。然而，目前對於設計師如何在開源軟體項目中做出貢獻，特別是關於貢獻的來源、貢獻的原因以及與開發工作相關的貢獻，了解甚少。
+
+設計有時由開發人員完成，有時由具有設計技能的人完成。很難理解這些角色和界限究竟在哪裡以及由誰來扮演，以及成功的最佳條件是什麼。
+
+通過我們對開源設計社區的參與，我們聽到了許多設計師關於參與障礙、缺乏貢獻任務和項目，以及如何作為設計師持續貢獻的故事。
+
+有關開源軟體項目中的“可用性”和“使用者”（超越“為解決自己的問題”而進行的開發者設計和構建開源軟體）在設計方面受到重視的關鍵研究已經完成 ([Raza & Capretz 2012](https://www.semanticscholar.org/paper/Do-open-source-software-developers-listen-to-their-Raza-Capretz/57f246785a3b0577ac98b10a61979853f3aafe14), [Hedberg & Iivari 2009](https://link.springer.com/chapter/10.1007/978-3-642-02032-2_22), [Bødker et al. 2007](https://dl.acm.org/doi/10.5555/1769821.1769824))，以及關於設計師在開源軟體項目中貢獻設計時所遇到的把關方法的研究 ([Rajanen et al. 2015](https://link.springer.com/chapter/10.1007/978-3-319-22698-9_2))。
+
+然而，幾乎沒有記錄和比較設計師在開源軟體中經歷的親身經歷的資料。
+
+## 1.1 研究架構
+
+為了更好地了解我們的參與者，我們首先進行了一系列大約45分鐘的半結構化訪談。在這些訪談中，我們詢問了一些關鍵的背景問題，例如：
+
+* 你是如何開始接觸開源軟體的？
+
+* 你是如何開始從事設計的？
+
+* 你參與並貢獻的是哪些開源軟體專案？
+
+* 你如何決定選擇一個你想要參與或貢獻的專案？
+
+* 你是作為一份有償工作還是義務（無償）貢獻開源軟體，或是兩者兼有？比例如何？有償/義務開源軟體工作對你來說感覺如何？
+
+* 你發現自己花最多時間做哪種類型的設計？使用者體驗設計（UX）？使用者界面設計（UI）？研究？
+
+* 你和其他開源軟體工作者之間發生什麼樣的流程和溝通？還有哪些其他人參與這個開源軟體？在什麼時候溝通有效，什麼時候溝通無效？
+
+* 展望未來，當你可能停止貢獻你現在參與的開源軟體專案時，你希望如何離開這個項目？在你看來，這個專案的設計方面應該是什麼樣子？
+
+我們從個別訪談轉向建立一個通過 Slack（群聊應用程序）共享的通信渠道，作為提醒和為參與研究的設計師提供支持的手段。初步訪談顯示，設計師們希望能夠與其他參與開源軟體的設計師交流，因為他們希望能與他們共同體驗和互動。這表明，儘管有些設計師社區和空間存在，但許多設計師無法進入這些社區，或是現有的社區和空間並不適合參與日誌研究的設計師。
+
+通過一系列問題（在 Google 表單中設置），設計師們使用這些問題來記錄他們每週的開源軟體日誌提交。他們還可以使用自由形式的文件、音頻錄音或視頻錄像來記錄。大多數設計師選擇通過表單中的問答功能來回應，一些設計師則要求額外的視頻會議來澄清細節，或通過在 Slack 中提出問題來澄清他們的需求。
+
+## 1.2 我們研究的對象及他們所貢獻的開源軟體專案概況
+
+我們發布了一個公開徵集，邀請設計師參與日誌研究，並儘可能選擇來自全球各地的人員，盡量避免只選取歷史上代表性較強國家的居民和公民。我們的參與者來自並居住於：加拿大、美國、尼日利亞、巴西和荷蘭。參與者中有60%認同為女性，40%認同為男性。60%的參與者處於設計（及開源軟體）職業生涯的早期階段，40%是研究生。所有參與研究的對象至少在開源軟體中貢獻了一年。
+
+參與者的身份如下：
+
+* 承包商自由職業者（服務部分開源軟體客戶，但並非全部，主要是志願開源軟體貢獻者）
+
+* 兼職研究生和兼職有償開源軟體設計師
+
+* 專職開源軟體專案設計師
+
+* 全職研究生獲得資助（志願開源軟體貢獻者）
+
+* 經營自己公司的個人（主要不服務開源軟體客戶）
+
+| 參與者 ID | 兼職 / 全職 | 就業狀況（合約工、員工、自僱等）               | 學生（研究生） | 參與的開源軟體專案 |
+|------------|--------------|---------------------------------------------|---------------|-------------------|
+| Grey       | 全職          | 自僱                                             | 否            | 2-3               |
+| Pink       | 兼職          | 合約工                                           | 是            | 3                 |
+| Yellow     | 全職          | 員工                                             | 否            | 3-5               |
+| Green      | 全職          | 自僱與合約工                                     | 否            | 4-6               |
+| Blue       | 全職          | 員工                                             | 是            | 2-3               |
+
+40%的參與者為他們的開源軟體貢獻獲得了報酬，而60%為無償志願者。
+
+在整個研究中，大約有十個開源軟體專案以某種方式得到了貢獻。這些專案包括教育工具、語言應用程式、網站、活動、瀏覽器擴展、開放數據、科學工具、學術工具和可視化工具。
+
+我們詢問了設計師們如何進入設計這一職業，20%的設計師最初是作為開發者開始的，另有40%有藝術和設計背景，40%有其他學科背景，例如音樂、行銷。大多數設計師參加過本科學位以外的課程，或通過網絡資源（如[Nielsen Norman Group](https://www.nngroup.com)或[Coursera](https://www.coursera.org/)）對用戶體驗或人機互動產生了興趣。
+
+## 1.3 這些設計師最初是如何參與開源軟體的？
+
+我們了解到，設計師發現並貢獻於開源軟體的方式多種多樣。許多人通過參與設計社區、編程語言社區、大學項目/團體，或圍繞特定開源軟體使用/目的而組成的群體（例如 Hacktoberfest、Linux 群體、Python 群體等）來找到他們的開源軟體途徑。關鍵的相似之處在於，早期在他們的開源軟體設計旅程中，所有人都與曾經作為貢獻者參與過開源軟體的人有接觸。從我們參與者的講述中可以看出，這些經歷大多是積極且支持性的，這強調了早期社區包容性經歷的重要性。
+
+有一位設計師同時認同自己是一名“開發者愛好者”，他在5-6年前參加了一個當地的Ruby編程語言聚會，大部分參與者都認同為開發者。他當時對此感到好奇，並希望作為一名愛好者找到一些社區參與，這最終導致了他持續參與某個特定的開源軟體專案。另一位參與者最初是以編碼者的身份認同並貢獻於開源軟體，但後來發現有一個開源軟體社區需要插畫和標誌，於是他們便貢獻了這些作品。他們通過參與和貢獻開源軟體社區，逐漸在設計職業上有所發展。
+
+有一位設計師在2021年開始了他的開源軟體旅程，當時他看到了一篇關於開源軟體設計的文章，然後加入了一個名為["Design Buddies"](https://discord.com/invite/designbuddies)的Discord社區。在那裡，他們搜索了開源軟體設計，並看到了一位社區成員的名字，於是他們發送了消息給這位成員。經過一系列有關開源軟體和設計的交流後，這位設計師提到了他們曾經用於音樂創作的一個開源軟體專案，並表達了想要在設計方面做出貢獻的意願。這最終在另一位社區成員的支持下，使他們完成了第一次設計貢獻。
+
+另一位設計師在大學時參與了一個FOSS計劃（[OpenRIT](https://openr.it/)），而這是他們在該計劃之外唯一的開源軟體貢獻經驗。畢業後，他們被雇用來設計開源軟體工具，並且從那時起一直在該公司工作。他們將自己的貢獻描述為完全有償的工作，但由於他們經常需要在志願時間內撰寫並提交籌款申請，以獲得某些設計工作的資金，這個定義變得有些模糊。這些設計工作在他們的開源軟體中並未被優先考慮到典型的資助週期中（例如撰寫資助申請），但他們認為這些設計工作對開源軟體至關重要。有一位設計師在看到朋友使用Linux機器並搭配免費和開源工具後，改變了他們整個工具生態系統。值得注意的是，這位設計師不懂編程，並且將自己與進步社會運動聯繫在一起。這位設計師提到，參與開源軟體的存在和過程讓他們感到“解放”和“倫理”。
+
+許多設計師對於開源軟體的動機是共同的。他們認為免費和開放的工具是“好”的，對技術生態系統有益，設計師希望為這些工具貢獻自己的時間和技能。當設計師了解“健康技術/基礎設施”目的時，他們能夠更好地理解專案的存在理由，並提供更相關的設計支持。設計師參與開源軟體的第二個常見原因是為了提升自己的技能，無論是通過有償還是無償貢獻，來提高自己的職業和作品集。
+
+## 1.4 設計師如何決定是否願意為某個開源軟體專案做出貢獻或參與工作？
+
+大多數設計師在決定是否為開源軟體貢獻時有著相似的考量。以下是設計師們決定開源軟體專案是否適合進行設計貢獻的常見方式：
+
+* 開源軟體專案對設計/設計師的需求是否合理清晰？專案是否明確設計師需要解決哪些問題？
+  
+* 我是否具備完成該技能/任務的能力？或者我是否能夠學習如何為該貢獻完成這項工作？
+
+* 專案的需求程度如何？是否有其他人能夠完成這項工作，或者專案是否有足夠的支持來在其他地方完成這項工作？
+
+* 這個開源軟體專案是否為單人專案且仍然活躍？
+
+* 這個開源軟體專案與我的文化/地理位置有多近？我能否以母語舒適地進行貢獻，並在我的語境下受到歡迎？
+
+* 文件對我來說是否易於理解？我能否學到足夠的開源軟體知識以便參與？
+
+一位設計師描述了開源軟體和設計貢獻在過程初期的一個問題： _“開源軟體（專案）不會經常創建設計問題。雖然開源軟體專案的人們可能知道存在問題，但他們不知道如何描述問題。很少有人或幾乎沒有人在管理問題或問題。”_ 這些問題被描述為“停滯的問題”。
+
+大多數設計師會查看開源軟體專案的GitHub，尋找“活動”及最近的問題。這有助於緩解一些設計師的擔憂，正如一位參與者在研究中描述的那樣：_“（我）猶豫是否要貢獻一個設計，擔心它會被拋進虛空，永遠不知道（並希望）有人會做些什麼。我想要確定性。”_ 設計師對專案活動的興趣延伸到他們活躍於其中的社交媒體平台，而這些平台開發者們並不活躍（例如Twitter、Dribbble、Behance、LinkedIn等）。如果開源軟體專案在他們看到的平台上是“活躍”的，那麼這個專案就是“活著”的。
+
+對於那些為專案工作而獲得報酬的設計師，他們將專案形容為被“交付”給他們，並且開源軟體專案的態度是 _“我們現在有一個用戶體驗設計師了！我們可以得到幫助。”_ 這些有償設計師有時可以選擇他們想要幫助的對象，但這通常由特定開源軟體的設計工作資金決定。如前所述，一位設計師通過撰寫自己的資金申請，在志願時間內提高開源軟體中被低估和忽視的部分（如無障礙性改進），從而將這一過程掌握在自己手中。
+
+具有邊緣化身份的人通常會根據開源軟體社區的包容性以及開源軟體與其文化背景的相關性來選擇要貢獻的專案。這通常是通過朋友向設計師推薦特定的開源軟體並保證其安全性來實現的。這些邊緣化的人們希望明確知道他們不僅會因其貢獻而受到重視，也會因為他們作為一個人的身份而被重視，因為他們試圖在開源軟體和技術領域中獲得更好的代表。這樣的考量對於開源設計師來說相對熟悉，因為設計和設計師在開源軟體中是一個邊緣化的職能，通常被低估和缺乏作為構建可用開源軟體的核心組成部分。
+
+參與研究的許多設計師認為，開源軟體不應該因缺乏設計貢獻而被忽視，因為設計在開源軟體領域中大多缺席。正如一位設計師所言，_“僅僅因為你沒有很多錢，並不意味著你不應該擁有一個合適的標誌/設計。”_ 這一觀點適用於所有形式的設計。我們的參與者對開源軟體專案進行貢獻時，設計師們經常因為開源軟體專案沒有實施他們的貢獻而感到沮喪。這與核心信念有關，即設計可以改進開源軟體，開源軟體也值得得到關注。
+
+## 1.5 設計師在為開源軟體貢獻時會用到哪些工具？
+
+我們想了解設計師在他們的貢獻過程中使用哪些工具。我們發現，在這項日誌研究中，設計師最常使用的設計工具是一個文字處理器，通常是 Google Docs，有一個案例中使用的是 Libre Office。這些工具主要用於設計研究相關文件以及用於溝通和澄清設計或執行設計工作的過程（例如可用性測試、無障礙性審查）。設計師們還使用 Notion，並主要將其描述為一種在團隊成員之間用來進行文檔記錄和共享的工具。
+
+設計師們使用的溝通工具主要取決於開源軟體維護者或專案所使用的工具，範圍從企業付費工具到開源軟體的通訊和工作共享工具。這些溝通工具，包括視頻會議和聊天工具有：Slack、Telegram、Discord、Webex、Zoom、電子郵件、Reddit/論壇、Internet Relay Chat (IRC)、Element/Matrix 和 Jitsi。有一位設計師描述了_“拿起電話給相關方打電話”的過程，這被描述為在決策和與相關方進行清晰溝通方面具有變革性的一步。同一位設計師還提到，與其他開源軟體貢獻者面對面見面並一起工作，對於促進他們的工作關係和當前設計工作非常重要。
+
+所有設計師在某些時候都會使用 GitHub 或 GitLab，無論是上傳圖像（.svg及其他文件類型）到相關 issue 和/或 pull request，還是與開發人員和其他開源軟體工作者進行溝通。
+
+兩位設計師同時積極地進行代碼編寫和設計任務，通常使用 Microsoft Visual Studio Code，同時也有提到他們有使用 Brackets 和 Codepen。
+
+一位參與者使用了一個特別的，名為 Hubilo 的事件工具來設置和組織他們貢獻的開源軟體事件。這位參與者還使用了另一個名為 Around.co 的視頻會議工具。其他使用的獨特工具包括 Audacity（通常用於音頻編輯工作）和 iMovie。這可能是因為有參與者正在開源軟體專案中處理音頻和視頻文件，例如需要將視頻內容上傳到事件網站或處理聲音文件的開源軟體。
+
+設計師們使用的設計工具是一個混合的組合，包括付費和免費的商業工具，例如 Adobe Suite（Photoshop、Illustrator等）、Figma、Canva、Pixlr、Axure RP（原型設計工具），以及一些開源軟體設計工具，如 Penpot、GIMP 和 Inkscape。另外，還提到了專門用於檢查顏色對比度的無障礙工具。
+
+一些設計師還提到在構建網站時使用常見的圖片瀏覽網站，如 Pinterest 和 Dribbble。
+
+值得注意的是，只有一位設計師描述他們如何使用紙筆完成他們的工作。
+
+## 1.6 在這十六週期間，他們共享了哪些設計產出物？
+
+大多數參與者分享的“設計產出物”包括用戶體驗（UX）研究書面文件、repositories（GitHub/GitLab）或網站信息。他們很少與我們分享用戶界面（UI）的設計進度，但他們描述了設計 UI 元素過程中的技術需求、與使用者和開源軟體專案開發者/擁有者的對話。儘管界面設計顯然在進行中，但問題是“為什麼這些設計如此罕見地被分享？”一個合理的解釋是，這些“設計產出物”（也在研究中與我們分享）是專門用於在開源軟體專案內部共享的，並且對於不同專業團隊之間的協作至關重要。可能有些參與研究的設計師希望展示“完成的”或“令人印象深刻的”設計產出物，而不是工作進行中的文件。
+
+四個設計貢獻集集中在特定技術的開源軟體活動以及運營這些活動所需的設計工作（例如插畫/圖形設計、商品設計、活動網站設計、表單設計等）。其餘的設計貢獻則是用戶研究文件（用戶測試計劃/腳本和啟發式分析）及其結果、可共享設計文件格式的UI/UX設計視覺效果、專案遵循的設計/視覺系統、無障礙性研究/設計以及在問題/拉取請求中的設計見解/指導。
+
+有些貢獻可能不完全是“設計”，而是溝通、協作準備、組織、社區協調和利害關係人管理。這些通常是使設計貢獻成為可能的基本任務。每位參與者都花費了時間在“設計貢獻”和圍繞設計的基本工作上。一些人更深入地涉足了專案管理、產品管理以及組織行政任務。
+
+# 2. 設計師與工程師之間的協作
+
+## 2.1 關於協作
+設計師和開發者的參與與合作是這項日誌研究中的一個反復出現的主題，揭示了設計在開發者及開源軟體中的其他角色中受到的重視程度，也反映了設計作為一個協作過程的本質，不僅受到使用者的影響，還受到業務/產品目標和技術限制的影響。
+
+有一位參與者報告說，他們比其他人更頻繁地參與編碼工作，花費多達50%的工作時間在編碼上。這位參與者提到了_“（開設了一個）公共儲存庫來啟動（開源軟體組織）的多樣性和包容性工作組網站”_和_“將其他團隊成員的部分內容合併到頁面上”_等活動。
+
+另一方面，其他參與者幾乎沒有提到編碼工作，甚至完全不提。一個關於對編碼態度的顯著例子是某位參與者的評論，_“我對儲存庫做了兩次提交。通常我讓其他人來處理GitHub。”_ 這位參與者甚至將這個經歷報告為他們這一週的亮點，這表明編碼作為一項活動是被積極看待的，甚至可能賦予了設計師力量。
+
+所有設計師都在某些時候使用了GitHub或GitLab——這些傳統上被視為開發者工具的平台，用於與開發者進行溝通和協作。然而，參與者也提到他們在使用這些工具時遇到了困難：_“（我）不確定如何最佳使用GitLab處理設計票據。”“我討厭GitLab，它令人困惑，而團隊尚未將我設置為開發者。”_
+
+一位參與者說，_“我不熟悉如何製作GitHub網頁，所以我不得不通過電子郵件發送內容反饋，而不是自己編輯”，這表明他們確實有興趣使用這些工具，但對工具的缺乏理解和上手過程帶來了挫折。
+
+相反，開發者更頻繁地參與到設計過程中，設計師們_“從開發者那裡獲得了關於設計提案的回應”。所有參與者都提到，從開發者那裡獲得反饋是他們過程中的關鍵一步。有一位參與者詳細描述了_“開發者決定簡化一個按鈕，移除不必要的文本，並建議一些圖標來替換文本”。設計師們經常會主動採取措施，以確保與開發者之間的更好合作，有一位參與者提到_“（我）製作了一個用戶流程圖來使我的設計更易理解”。這些努力的成果也得到了認可，正如一位參與者報告的那樣，_“一位開發者發現我整理的Figma文件非常有用”。
+
+我們可以清楚地看到，在受到興趣驅使和鼓勵時，開發者能夠參與他們所屬開源軟體的設計方面的討論。在這項研究中，設計師們在持續不斷地努力從各個角度理解開源軟體。這讓我們了解到，缺乏溝通和反饋可能會阻礙設計師在開源軟體中的有成效的參與，因為設計的成功依賴於協作和合作。
+
+顯而易見的是，將設計師排除在開發者領域內的開源軟體方面（如對儲存庫的訪問權限、合併代碼的能力或了解網站/數字基礎設施的設置方式）之外，會創造出這項研究中捕捉到的知識差距，並使設計師在由開發者主導的開源軟體領域中感到疏離和無力。
+
+## 2.2 開放實踐
+對於大多數設計師而言，開源軟體的過程在設計方面足夠透明，而一些設計師也為開放他們的設計及其整體工作做出了其他努力。
+
+參與者與社區及其他利益相關者共享資產和資源，以努力變得更加開放。共享這些資產的行為也受到他們所工作的組織流程的限制，正如一位參與者提到的那樣，他們_“在設計獲得批准之前無法向研究團隊提交任何設計作品”_。
+
+有一位參與者_“邀請新的開源設計貢獻者參與專案”，另一位參與者_“加入了另一個（地理位置）社區……主要關注於自由文化和通訊”_，表明他們與他們所屬的社區以及新的開源軟體社區互動，以努力變得更加開放。
+
+有一位參與者提到轉向使用開源工具以變得更加開放，他們還報告了使用先前的非開源設計工具時遇到的問題。_“我正在努力中！使用 Penpot 而不是 Figma，也許？”“Penpot 還不能在頁面之間導航。”_
+
+一個不常被提及的開放性方面是用戶如何能夠公開訪問開源軟體。一位設計師提到，通過他們的設計工作，使用者能夠‘發現’這個開放工具並與他們的家庭一起使用它。_“我不確定這算不算，但這是第一次，我們地區的大多數父母發現了這個可以給他們的孩子使用的免費（而且是開源的）學習工具。”_
+
+開放的動機似乎遵循了一些普遍的主題。參與者共享他們的資產和資源是為了與利益相關者更容易地合作，正如一位參與者所述，他_“嘗試重新組織我的 Figma 設計，以便更好地交接”，推測是指與開發者的交接，另一位參與者_“為所有講者創建了一個講者工具包，內含設計資產和幻燈片模板”。這些資產據報受到了共享對象的積極回應。_“我收到了一些人對我分享的開放設計資源的反饋，說這些資源對他們有幫助，他們將會使用我們的貢獻。”_
+
+不開放設計所固有的風險在一次互動中得到了體現，當時_“[一位] 合作設計師拿錯了設計文件，並在他的工作中使用了過時的資產。所以這需要被撤回並重新做。”_
+
+另一個共享資產的動機是希望社區有更多的參與，如一位參與者_“與（開源軟體社區組織）團隊分享了文件，讓其他設計師可以提供意見”_。增長和強化社區本身也是一個動機，無論是通過與社區其他成員互動，還是通過適當地給予他們應得的榮譽_“除了我的設計貢獻之外，我還與其他開源設計師和坑主（專案擁有者）討論了 2023 年開源軟體中設計的未來。”_
+
+然而，增長一個社區並非易事。一位設計師談到他們努力‘開放’自己的過程，並要求更多的設計師參與。結果似乎並不如願_“我仍然承受著一如既往的壓力。我希望今年通過與更大的開源設計社區對話來採取一個壓力較小但更有利可圖的行動。”_這表明設計師需要在專注於開放性或獨自進行工作之間進行努力的權衡。這兩者都需要付出努力，而設計師（就像開源軟體中的其他功能一樣）時間有限，他們必須在選擇是否進一步開放時做出謹慎且具有風險的決定。
+
+# 3. 當設計師談到「成功」的定義
+
+## 3.1 「反饋」作為一種成功
+設計師在衡量專案成功時採用了兩種略有對比的方式：一是在沒有收到反饋（但也沒有遇到阻力）的情況下，另一種是在收到反饋（且只有低或可理解的阻力）的情況下。設計師認為，如果他們收到的反饋是相關且有用的，他們的工作就算是成功的。通常，設計師認為他們的設計是成功的，這並不令人驚訝，因為他們使用了易用性測試和使用者互動來指導設計。
+
+當設計師沒有收到關於他們的設計工作的問題或反饋時，他們往往會假設「他們已經做對了」（即成功了）。如果設計師對他們提議的設計不特別自信，那麼這種情況就不那麼明顯。
+
+參與者對“緩慢”的反饋持負面看法——缺乏溝通被視為進度的障礙。參與者提到的兩種類型的“沒有反饋”需要區分。一種是積極的，即設計是“好的”，不需要更改；另一種是消極的，即來自其他利益相關者的缺乏任何反饋，這讓人感到沮喪，因為它阻礙了進展。這兩者之間的區別可能會讓人困惑，但可以通過注意反饋事件之前的溝通性質來了解。如果之前的溝通是積極且活躍的，那麼沒有反饋是好的。如果之前的溝通缺乏且一般是消極的，那麼沒有反饋就是不好的。
+
+一位參與者將“可用的反饋”描述為最佳的反饋，指的是那些具體到足以在需要的地方提供指導但不會對設計作為改進方法產生阻力的反饋。一位設計師一致地將成功描述為_“當我得到關於我的設計中錯誤的反饋並獲得可行的下一步建議時”。我們作為研究人員，想要強調這裡使用的“錯誤”一詞。從質性數據中可以看出，設計師花了大量時間與利益相關者和開源軟體專案貢獻者以及開源軟體工具的使用者進行溝通、理解和合作。“錯誤”可能指代許多具體的互動，最有可能的是開源軟體專案維護者的意見是“正確的”，而設計師是“錯誤的”（或者可能從技術能力和/或規範的角度來看是誤解的）。設計師依賴開源軟體專案的開發者和維護者在設計過程中定義什麼是“正確的”。在開源軟體領域之外，設計師通常依賴通過直接研究或設計假設過程來預測和探索用戶需求的“使用者”觀點。
+
+開源專案的需求通常以稱為問題（issues）的簡短問題描述來描述，並在網絡平台上管理。這對於代碼及與代碼相關的任務來說非常常見。然而，設計任務在這些平台上往往不存在。如果存在，通常缺少細節。因此，設計師的問題與開發問題的模式並不相同。
+
+值得注意的是，儘管“問題”是開發者/編碼人員定義開源軟體工作方式的方式，但設計師傾向於依賴簡要文件（這些文件在語氣上類似於問題標準，但通常更加冗長），以及與“客戶”或“厲害關係人”的反覆合作和反饋周期。通過撿起一個問題，編寫代碼，提交拉取請求(pull request)並獲得逐行反饋來“自給自足”的概念並不是設計師（跨用戶界面、用戶體驗和設計研究）所熟悉的做法，可以說這也不是一種適用於設計過程的做法。在軟體開發中的設計，特別是開源軟體中，我們觀察到了一種持續的緊張狀態，這種開源軟體是更分散的、分段的、遠程的，並且在溝通、知識和時間上存在“缺口”——除非設計師能夠主張自己是用戶的聲音，並將設計過程作為定義“正確”與“錯誤”的過程，否則“正確”和“錯誤”將由開發者和維護者的意見和時間來定義。
+
+理論上，設計師可以主張自己是用戶的聲音，並且他們所使用的設計過程中的證據定義了什麼是“正確”或“錯誤”。然而，由於設計師在開源軟體專案中的邊緣化地位，他們大多無法自己定義這一點。因此，他們會依賴更有權力的開發者來定義他們設計貢獻中的“正確”或“錯誤”。“流程：誰做了決定以及他們是怎麼做決定的？”這一部分探討了設計師在權力差異以及治理文件的存在與近用性方面的問題。
+
+這些意見對於軟體的良好生產仍然至關重要，因為它們包含了技術能力和整體專案理解的見解，但當涉及到提供有見地且經驗豐富的設計相關反饋時，開發者和維護者不應該被要求達到“標準”。特別是在設計可能不是他們專業領域或學習知識的情況下。
+
+為支持圍繞設計意見的討論，一位設計師的評論表明了問題的根源——_“如果利益相關者能在 Slack 或同步會議中理解我的意思並能給出反饋（會很好）。”_ 我們注意到，設計及其使用的過程有時不為那些沒有設計或設計過程經驗的人所理解。因此，除了“這很好”、“這不好/我不喜歡”之外，他們可能難以對設計做出有效的反饋。
+
+如果設計師不確定一個設計是否會被接受，這意味著他們可能會延遲工作。一位參與者說：_“在我與維護者的先前對話中，反饋有所延遲，因此我無法立即啟動”_，以及_“我嘗試與在專案上留言的維護者進行通話。反饋也很緩慢。”_
+
+從數據中我們看到設計師等待的關鍵反饋間隔在一週到三到四週之間。這往往會促使設計師堅持尋求反饋，或者在某些情況下轉向另一個反饋更穩定和快速的專案。如在[“設計師如何決定是否願意為某個開源軟體專案做出貢獻或參與工作？”](https://github.com/simplysecure/Diary-Studies-Designers-in-OSS/blob/main/findings-report.md#how-do-designers-decide-whether-theyd-like-to-contribute-to-or-work-on-an-oss-project)部分討論的那樣，設計師想知道他們是否在增加價值，並且是否為專案所需要。
+
+## 3.2 「上線」與「落地」作為一種成功
+
+所有設計師都對於那些已“上線”的貢獻感到普遍的慶祝，比如網站被公眾或專案外部的人訪問。_“當他們說‘看起來很棒’並要求文件時，我知道設計已經被接受了”_，這是一位設計師對成功完成的描述。
+
+然而，大多數設計師對於何時某些內容會上線感到不確定，特別是在他們無法控制過程或實際發布作品的情況下。_“不確定哪些設計會在何時實施，因為我們沒有使用產品管理策略。”_
+
+設計師們還表達了對於設計已經準備好上線卻被多輪審批耽擱，甚至最糟糕的是由於開發者或維護者要求進行設計更改而感到沮喪。_“標誌已經完成了，在我看來它並沒有那麼好，但它是可用的，然後有些人開始對其進行過多的考量並想要更改。這很不好，因為我們在材料和社交媒體內容上已經有點遲了。”_
+
+## 3.3 「了解開源專案開發的輕重緩急」作為一種成功
+
+衡量優先事項的進展是困難的，一位設計師持續提到需要一位產品或專案經理來指導他們完成最優先的任務。這項研究中的設計師們表示，他們對於應該做什麼以及何時做有“良好的想法”，並且對自己所掌握的知識充滿信心，這些知識要麼基於開源軟體專案開發者/維護者的信息和反饋，要麼基於用戶研究和反饋。從研究人員的角度來看，我們看到設計師在設計工作中使用了既定的用戶研究和用戶見解的收集方法，並通過徹底的過程來檢查他們的假設。
+
+設計師們採用了許多策略，以便在缺乏記錄的路線圖或專案計劃的情況下更好地理解優先事項，或者當開源軟體計劃只存在於某個人或開源社區成員的集體心中且可能隨時更改時，設計師們會進行學習。一位參與者描述了一種從利害關係人那裡學習的方法：_“這不算什麼技巧，但我已經開始讓重要的利害關係人（通常是專案負責人）更多地草擬他們的想法，這樣我就知道他們在想什麼。”_
+
+設計師們評論說，開源軟體的落地_“並沒有明確的路線圖”_，儘管問題和會議提供了一條路徑，但這些路徑並不總是一致的，也不總是指示出更廣泛的目標。在那些有外部截止日期的開源軟體專案中（例如活動和年會），這並不會構成太大的問題，而且當設計師在特定專案中具有一定的權威性和/或受到高度尊重時，這也不是很大的問題。請參見[“流程：誰做了決定以及他們是怎麼做決定的？”](https://github.com/simplysecure/Diary-Studies-Designers-in-OSS/blob/main/findings-report.md#processes-who-makes-decisions-and-how-are-they-made)部分，以獲取有關權力和治理的更多細節。
+
+總體而言，當涉及到開源軟體中的設計優先事項時，許多專案仍然對決定設計應該關注的重點感到緊張，因為除非已經收集並理解了用戶研究或用戶見解，否則就會出現一個問題，即誰的意見在開源軟體中具有優先權，他們以何種方式信任設計變更？正如一位設計師所說：_“大多數專案仍然對進行設計更改持懷疑態度。”_
+
+## 3.4 「吸引更多設計師加入開源專案」作為一種成功
+
+在這項研究中，一個微妙的成功衡量標準和設計師所表達的喜悅是能夠與其他設計師合作。當設計師在他們貢獻的開源軟體專案中與其他角色一起進行設計任務時，他們也表現出了同樣的喜悅。一位設計師有一個明確的目標，即通過分發和構建任務的方式吸引更多設計師參與專案。_“今年開源軟體社區的目標是建立網絡並吸引更多設計師。我們從過去的活動中了解到，網絡研討會、工作坊和 Twitter 空間是吸引非洲貢獻者的最佳方式。”_
+
+在開源軟體中為設計任務聚集合作者時，已有開源經驗的設計師意識到，大多數設計師都是新手，他們希望通過貢獻來獲得某些類型的經驗。_“這是一個挑戰，因為大多數尋求貢獻的設計師都是新手，他們貢獻開源是為了獲得經驗。”_ 我們觀察到這對於設計師貢獻者來說可能會帶來兩個關鍵原因的困難——時間和責任感。設計師可以花在開源軟體上的時間通常有限，因為他們可能會花時間在與設計相關的任務上。當新增的設計師是新手時，他們通常會管理設計工作，並提供良好的任務來為新設計師提供經驗。許多研究中的設計師表達了 _“想要做實際的設計工作” 的願望_，因此作為開源軟體專案中已建立的設計師，他們感到必須為新設計師提供良好體驗的責任很高。
+
+對於這項研究中的特定開源軟體專案的未來希望，是增加參與開源軟體設計任務的設計師人數可以 _“減少我和其他活躍貢獻者的壓力”。_ 在十六週的日誌研究期間，我們沒有觀察到增加設計師人數對開源軟體有影響，但我們懷疑這些益處可能超出了十六週的日誌期間。我們需要在這項研究中觀察超過十六週的時間才能發現其益處和挑戰。
+
+雖然更多設計師對開源軟體的貢獻意味著成功，但具體情況可能會很棘手：_“與其他設計師合作有時很難傳達你想要保持的一致設計風格。”_ 當與其他設計師的合作不順利時，隨後為了保持一致性而進行的“團體協調和設計修正”可能是複雜的工作，並且可能無意中傳達出設計效率不足的錯誤印象。當這些複雜情況出現時，我們可以將其視為開源軟體工具和平台中缺乏對設計的支持所帶來的障礙。
+
+對於大多數在開源軟體中的設計師來說，現實情況是他們主要是單獨進行設計任務。_“大多數時候，我是唯一一個在設計的，因為其餘團隊成員主要是開發者。”_ 大多數單獨工作的設計師在能夠與任何人合作時都表現出極大的喜悅，並樂於分享集體努力創造的文件和圖表。
+
+除了吸引其他設計師專門參與開源軟體之外，一位參與者在多次場合提到了對產品/專案管理的需求，以及他們一直在執行產品管理任務。他們認為透過貢獻得到產品經理的幫助為一種成功 _“我需要更多的組織技能來幫忙分配我需要完成的任務——換句話說就是需要產品經理！”_ 。
+
+## 3.5 「實踐理解、包容、與協作」作為一種成功
+
+正面認可是促進成功的重要動力，不僅如此，還有助於參與者在貢獻開源軟體時獲得愉快的體驗。在整個日誌研究期間，所有設計師都收到了整體積極的評價。其中一些評論針對具體的設計，一些則直接來自對可用性測試和設計改進感到興奮的使用者。
+
+這些評論展示了設計師收到的正面反饋類型，這些反饋鼓勵他們繼續貢獻。_“我們收到了正面的反饋，並與對這款軟體感到非常興奮的社區成員會面”_以及_“登陸頁面受到了公眾的好評”。_以下評論還伴隨著另一個“成功”指標，即為他們的設計工作確定發布或上線日期。_“我收到了關於我為開源軟體專案設計的標誌的非常積極的反應，並且已計劃新標誌的發布日期。”_
+
+對設計的積極影響表示讚賞和認可的另一個好處是，它可以讓開源軟體中的其他角色和功能對設計過程產生興趣並投入其中。_“Django 團隊讚揚了我做的網站設計，這讓他們對我的工作產生了興趣。”_一位設計師解釋說，這表明這個團隊未來有可能在同步設計合作的形式上進行更多的設計合作和參與。_“是的，我喜歡在模擬我們討論的過程中與（使用者）和工程師/開發者交談。”_
+
+還有一些例子表明，設計師或設計（作為一種實踐）被誤解或錯誤表述，或者設計師未被納入某些開源軟體過程中。_“參與一個會議被錯誤地表述，這讓人感到沮喪。”_
+
+兩位設計師提到被排除在 GitLab 平台之外，這意味著他們無法參與，影響了他們的貢獻和對開源軟體的情緒。_“我討厭GitLab，它令人困惑，而團隊還沒有把我設置為開發者”，以及“這是我第一次使用 GitLab 進行文檔處理。作為設計師，我從來不需要使用這樣的工具。”_ 確保設計師以賦權的方式被引導到平台和工具上是關鍵，這樣他們才能感覺到自己被納入了專案中。這可以通過提前讓他們了解他們將擁有的工具訪問權限，以及開源軟體開發者和維護者在入職前詢問設計師的知識水平來實現。這一點在以下關於設計師的評論中進一步探討，他們感覺自己並非社區的一部分，並且作為局外人有些困難。_“我注意到，如果你不是社區的一部分，那麼作為設計師貢獻會很困難。”_
+
+在開源軟體中，包容性和協作的困難更為複雜，設計師經常在與開發者、維護者和使用者的協作情況下難以表達自己的意見，因為這些人經常長時間討論某些問題或話題，而設計師並不總是感覺有權力將討論引導回到他們需要進行成功設計貢獻的地方。_“我是否應該讓某人繼續充滿激情地說話，因為這有點偏離了會議的主題？他們的意見是有效的，但只有一部分是相關的。”_
+
+## 3.6 「解決可取用性與易用性問題」作為一種成功
+
+在整個日誌研究期間，有許多評論涉及不僅僅是開源軟體產品的可訪問性，還包括開源軟體貢獻過程的可訪問性。設計師似乎意識到當開源軟體未達到可訪問性和可用性標準時的情況，但只有兩位設計師專門致力於改善他們選擇的開源軟體的可訪問性和可用性的貢獻。_“我們不會使用Tab鍵作為使用螢幕閱讀器/鍵盤從開源軟體的單元格導航到另一個單元格的方法。我們實施了這個功能，進行了測試，並收到了這不符合偏好的反饋。”_ 我們可以看到，將可訪問性作為設計“任務”的目標與通過實施和用戶測試來確定其成功與否的過程之間有更直接的關聯。
+
+另一位設計師提到，只有當審計文件中列出的所有可訪問性目標都得到解決後，才能說專案取得了成功。_“我們為專案設立了可訪問性目標，一旦我們達到了所有這些目標，我們就可以說專案是成功的。”_
+
+其他設計師的評論更多地涉及他們對設計實踐的態度，以及注意到這些缺乏可訪問性和可用性的時刻。_“為了測試開源軟體產品，我們不得不下載軟體。但它還不是每個人都能下載的。”_ 這條評論展示了當特定操作系統版本不可用時，某些使用者如何被排除在外。例如，一個開源軟體可能有一個適用於安卓設備的版本，但沒有適用於蘋果設備的版本。
+
+從一般意義上來說，設計師試圖將用戶的聲音納入考量，其中包括他們在可訪問性和可用性方面的困難。 _“我通常會試圖成為用戶的聲音。”_ 當與可訪問性和可用性相關的任務不是明確提出時，我們會看到可訪問性和可用性被忽視，而不是由設計師或開源軟體專案明確處理，而是優先處理其他更重要或時間緊迫的工作。這並不令人驚訝，因為我們有證據表明設計師們一直在表示，他們並沒有足夠的時間以他們希望的方式處理任務，並且他們在（與他人）溝通設計動機上的困難是存在的。