前言
前幾天，我在 X 上隨手投稿了一張「如果日本企業建置 GitHub 會長這樣」的圖片。
很感謝大家，這篇居然爆紅到難以置信的程度。
竟然累積了數千則轉推、超過 2 萬個讚，曝光次數更超過 400 萬次。
我一邊看著不斷湧入的通知欄，以及轉推引用裡飄來的「哇，很像會發生……」「胃好痛」「這不就是我們公司的內部系統嗎」等哀嚎，一邊在想：
「大家到底被 JTC（傳統日式企業）傷害得有多深啊……？」
JTC：Japanese Traditional Company
重新來看我投稿的圖片裡都塞了哪些元素吧。
- 明明是儲存庫詳細頁，內容卻滿滿都是
設計書_基本設計書.xlsx、構成圖.pptx之類的 Office 文件 - 明明應該是 Git（版本控制系統），卻莫名在瀏覽器上端坐著一個「上傳」按鈕，還附帶「※單次可上傳的檔案大小上限為 100MB。」這種限制
- 畫面下方端坐著長達 5 階段的「變更登錄流程（目前狀態）」，像上司核准、品質保證部門審查、安全檢查等等
- 公告欄裡排滿了「【再次通知】請定期變更密碼（至 6 月 30 日止）」和「關於 Git 操作之注意事項」之類讓人胃痛的內部規範
雖然是 AI 生成的圖片，但冷靜想想，這些其實全都是 JTC 的某些系統裡真實存在過（或曾經存在過）的規格。
為什麼明明組織裡應該有優秀的工程師和設計師，一旦做起業務系統，卻總會誕生這種像「警告與手續的集合體」一樣的 UI 呢？
把它單純歸結為「設計師沒有品味」很簡單，但我認為，那些難用 UI 的背後，其實藏著日本傳統組織所面臨的結構性問題。
所以，這篇文章就來非常認真地探討看看，為什麼會誕生那種 UI。
為什麼「紅字注意事項」會無限增殖
打開業務系統首頁，紅字或粗體的注意事項多到滿出來。
【再次通知】請定期變更密碼（至 6 月 30 日止）
※單次可上傳的檔案大小上限為 100MB。
關於 Git 操作之注意事項
畫面有 8 成都被「注意」與「警告」塞滿了。
為什麼會變成這樣？
原因非常單純。
因為文化上會把責任歸咎於「系統」，而不是「出錯的人」
在 JTC 裡，當使用者因誤操作刪掉資料、或發生誤寄之類的事情時，組織的反應通常會是這樣：
「為什麼系統端沒有設計成能防止誤操作？」
「為什麼畫面上沒有顯示提醒？」
被責備的不是粗心的使用者，而是系統開發端或營運端。
因此，開發團隊所能採取的最低成本、最方便的責任切割手段，就是在畫面上加上注意事項。
你看，畫面上用紅字寫著吧？沒讀的人就是使用者自己的責任。
這種就是為了免責而加上的注意事項。
每次發生問題，就不斷追加這些免責用的紅字，結果畫面就變成了注意事項垃圾桶。
那不是給使用者的 UI，而是開發者用來保護自己的「盔甲」。
為什麼「印章」和「紙本申請」的隱喻會被保留下來
前面那張圖裡最醒目的，就是「變更登錄流程（目前狀態）」。
不是按下「Approve」就能合併，而是排著「1. 變更登錄（登錄者：山田太郎）」→「2. 上司核准（核准者：佐藤課長）」→「3. 品質保證部門審查」這種超硬派的核准蓋章接力賽。
你可能會想：「都什麼年代了還在講印章，太好笑了吧。」但實際上的業務系統，卻確實被「換個形式的數位印章（核准工作流程）」大量寄生著。
為什麼會這樣？
因為他們往往不是在思考如何讓業務流程配合系統（BPR），而是直接放棄，改成把既有的印章流程原封不動地系統化。
原本導入 GitHub 這類現代工具的意義，不只是工具本身的功能，更應該是導入其背後的「扁平化審查」、「非同步溝通」與「開發者自主性」。
但組織端往往會說：
「我們公司的規定是，發佈一定要有部長決裁（蓋章）。這點不能改。」
結果，Git 的「Approve」這種簡單功能被硬生生翻譯成了「稟議」（立案、傳閱、決裁），最後就誕生了那種「為了合併，必須像集章活動一樣集滿佐藤課長的上司核准與品質保證部門審查」的變更登錄流程。
就算只是把工具換新了，如果組織「如何承擔責任」的方式沒有改，內容也只會一直停留在昭和時代的稟議書而已。
為什麼資訊會被硬塞進同一個畫面
從「XcodeManager」也看得出來，日本的業務系統就是一點空白都沒有。
「入口網站」「開發管理」「設定管理」「變更管理」「發佈管理」「品質管理」「資產管理」「共通管理」這些壓倒性的頁籤選單，再加上側邊欄、公告、捷徑、待辦清單、問題單列表、Pull Request 列表，全都用超小字體硬擠在同一個畫面裡。
當設計師提議：「我們應該留一些留白，把資訊整理一下。」時，決策者——主要是那些位高權重的大叔們——就會丟出強烈的咒語：
「還要捲動才看得到很難用」
「我要在一個畫面內掌握所有資訊」
對他們來說，捲動是「惡」，留白是「偷懶」。
如果把資訊整理成分頁，或分成不同頁面，接著又會被猛烈抱怨「資訊被藏起來找不到」「不能一鍵直接到達」。
結果，開發團隊開始害怕留白，於是把所有資訊都塞進同一個畫面裡，於是名為儀表板、實為「資訊過載暴力」的東西就誕生了。
美好的 UI/UX，是由「資訊減法」決定的。
但業務系統的 UI，卻是靠「責任加法」與「避免被抱怨的加法」把畫面一層層塞滿。
需求定義中「稽核／資安部門」的壓倒性權力
為什麼這種難用 UI 沒人能阻止？
我想，原因可能是因為在需求定義與驗收階段，沒有任何衡量「好不好用」（UX）的指標（KPI）吧。
你就算說「這個畫面比以前好用 3 倍！」，也不會有人因此給你評價，更不會因此拿到預算。
相對地，「資訊外洩風險」或「稽核合規」這種東西，只要出事，負責人可能立刻就會丟工作，屬於極強力的負面指標。
這樣一來，力量對比瞬間就決定了。
- 開發／設計師：「為了提升使用體驗，我們想把 session 維持時間拉長。」
- 資安部門：「有資安風險。10 分鐘自動登出，每次都要強制輸入一次性密碼。」
因為 UX 端沒有能推翻它的「大義名分（數字）」，所以犧牲好用性、名為安全、實為刁難的規格就會無條件通過。
禁止右鍵、禁止複製貼上、20 字以上的複雜密碼……
這些「不好用的 UI」，甚至可能就是資安部門為了證明「我有在做事」而刻意做出來的成果。
總結：好用的 UI/UX，是從「信任的設計」而生
說到底，那些充滿警告、綁手綁腳的業務系統 UI，在我看來，正是系統不信任使用者、而組織也不信任成員的表現。
「反正使用者一定會出錯」
「反正使用者一定不會遵守規則」
「所以就用系統把他們綁住，在畫面上大大寫警告，再用層層核准流程監控」
這種基於「性惡說」的思維，塑造了那種充滿雜訊的 UI。
反過來說，GitHub 等現代 IT 工具之所以 UI 簡潔，也不只是因為設計師厲害而已。
我認為，正是因為有著以「開發者是專業人士，是值得信任的存在」為前提的「性善說」與「自主性」文化，才能維持那樣簡潔的畫面。
如果我們真的想改善公司內部那些「難用的業務系統」，該改的不是 UI 的 CSS 或框架，而是組織「如何承擔責任」的方式，以及對成員的「信任設計」本身。
如果你覺得有趣，請幫我按個讚和收藏！
原文出處：https://qiita.com/Shiro_Shihi/items/4928640d01c78480962b
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
