【譯】設計系統清單——設計系統系列

原文傳送門：Design System Checklist

此清單是更大的

第一部分 → 設計系統的五大支柱

第二部分 → 設計系統清單

第三部分 → 設計系統資源和連接

---

支柱1 - 出售咱們的設計系統

目標

• 咱們的利益相關者指望什麼
• 咱們的指望是什麼？ （它有多完美？這些指望是否知足？）
• 誰將使用這個設計系統？ （開發者，代理商，內容編輯，...）
• 咱們是爲多種產品設計的嗎？

---

範圍

咱們將提供什麼：

• 原則*（品牌價值，目的，......，限制它們！）*
• 風格指南*（視覺）*
• 用戶體驗模式*（互動，最佳實踐......）*
• HTML / CSS實用程序類*（排版，顏色，按鈕，表單......）*
• 功能組件*（可在你的應用內使用）*
• 複製*（措辭，語氣，...）*
• 圖標，插圖和圖像
• 聲音和動畫庫

---

利益相關者和流程

• 咱們的團隊須要哪些角色才能得到成功？
• 咱們的設計過程應該涉及哪些專業？ （業務，產品，軟件開發和運維，測試，支持，......）
• 咱們是否已經得到了團隊和利益相關方的支持？
• 咱們須要知足哪些可交付成果和截止日期？
• 咱們的系統在初始開發過程當中是否已經在產品中使用過，或者咱們是否已經發布了完成的v.1？
• 誰須要簽署咱們的工做以及在哪些步驟？
• 咱們的設計系統的路線圖是什麼？將來如何維護？（範圍，MVP，迭代，擴展，......）

支柱2 - 研究咱們的設計系統

初始設置

• 它是從新設計仍是全新的？（遷移舊應用程序 可能會出現全局性CSS類的意外效果）
• 咱們遵循哪些規則和原則？
• 目前的設計在哪裏運做良好？
• 咱們能夠改進現有的設計？
• 咱們想要一個嚴格或寬鬆的設計系統嗎？
• 咱們從哪裏能夠汲取靈感？ （良好的複製/參考其餘>槽糕的自創）
• 咱們是否認義了最重要的術語來傳達咱們的設計系統？（設計師，開發者和利益相關者必須講一樣的術語）

---

用戶

• 咱們有足夠的看法來理解它們嗎？（歷程，JTBD）
• 咱們的應用程序有哪些背景？
• 他們與咱們的應用程序交互的頻率如何？
• 他們想要使用咱們的應用嗎？
• 咱們的觀衆對咱們的主題有多少了解？
• 咱們的用戶是否會接受培訓或從零知識開始？（B2E，B2B）
• 是否有咱們的觀衆指望的標準或API？（一般是B2B中的狀況）
• 咱們會知足哪些殘障人士？

---

技術

• 什麼輸出渠道適合咱們的觀衆？（網絡，移動，API，服務......）
• 技術堆棧對咱們的設計有影響嗎？
• 咱們將提供什麼？（視覺指南，html和css模板， 功能組件，......）
• 咱們須要個性化的賬戶和不一樣的角色嗎？（B2C，B2E）
• 訪問受限區域內的功能或組件是？
• 將集成哪些系統或來源？
• 咱們須要實時數據嗎？（數據是否須要推送到前端，例如使用websockets，或者前端是否會主動輪詢數據）

支柱3 - 設計咱們的設計系統

佈局和內容

• 咱們設計了哪些屏幕尺寸和輸入法？
• 不一樣產品和平臺的一致性如何？
• 咱們指望什麼類型的內容 （數據，主要是文本和圖像，產品......）
• 咱們在哪裏能夠看到最高的複雜性，不管是視覺仍是功能？（表格，表格，儀表板，產品，結帳......）
• 會不會有外語和他們的需求？ （RTL / LTR，標籤須要多長時間？）
• 誰會負責寫文字/文案？ （咱們的設計系統的標籤和描述性文字）
• 咱們的信息架構對導航有何要求？（深度，寬度，3年內有多少層級？）
• 用戶將如何導航？（菜單導航和/或內容，主 - 細節視圖，搜索，對話框......）
• 用戶是否能夠自定義他的視圖？
• 咱們的系統可以個性化嗎？
• 咱們是創建在現有設計系統或框架之上的嗎？ （材料，Bootstrap，......）
• 咱們的網格外觀和感受如何？（外觀，列，空白）
• 咱們的產品須要哪些組件？ （建立庫存，標記您已擁有但再也不須要的庫存）

支柱4 - 創建咱們的設計系統

操縱數據

• 用戶在哪裏編輯內容？（對話框，內聯，彈出窗體，......）
• 自動保存或保存按鈕？
• 咱們須要內聯編輯*（複雜的驗證規則會發生什麼？）*

---

錯誤預防和錯誤容錯

• 咱們什麼時候驗證用戶輸入以及如何顯示驗證消息？（對多個領域的複雜驗證）
• 是否有撤銷選項，若是咱們沒有用戶，咱們的用戶風險有多大？（對自動保存特別重要）
• 咱們須要歷史嗎？（記錄，回滾）
• 會話超時會發生什麼？（例如，有人在次日在打開的瀏覽器窗口中恢復任務，但會話已超時）
• 咱們是否可使用合理性檢查來防止錯誤發生以前？

---

通知

• 須要什麼級別的通知？ （信息，成功，警告，錯誤，嚴重）
• 咱們在哪裏展現它們？
• 除了屏幕以外還使用了哪些頻道？ （推送，電子郵件，短信，信息屏幕......）
• 若是用戶錯過了重要通知，可能會致使真正的問題嗎？

---

測試和文檔

• 咱們什麼時候以及如何運行可用性測試？
• 咱們如何測試設計系統的代碼？
• 咱們應該記錄哪些部分？ （模式，組件，代碼，作和不作）
• 咱們在哪裏能夠記錄它？

支柱5 - 維護咱們的設計系統

積分

• 咱們的構建管道是否容許自動化？
• 咱們如何自動化測試？
• 咱們如何設計咱們的設計系統？（語義版本控制）
• 產品團隊提交請求的過程是什麼？ （功能，只有錯誤修正，測試）
• 咱們是否須要具備請求須要傳遞的規則才能使其進入設計系統？
• 咱們使用哪些渠道向咱們的產品團隊通知新版本？
• 誰更新新版本的更改日誌併發送新聞稿？

---

縮放

• 全部產品是否都須要整個設計系統，仍是能夠將其分組到插件中？
• 咱們的產品團隊容許對咱們的設計系統進行哪些調整？
• 產品團隊能夠實施他們本身的組件版本嗎？
• 咱們如何添加，棄用和刪除組件？

其餘參考：

• JTBD：The Jobs-To-Be-Done Framework

譯者簡介：土撥鼠，蘆葦科技web前端開發工程師，表明做品：飛花亭小程序、續航基因、YY表情紅包、YY疊方塊直播競賽小遊戲。擅長網站建設、公衆號開發、微信小程序開發、小遊戲、公衆號開發，專一於前端框架、服務端渲染、SEO技術、交互設計、圖像繪製、數據分析等研究，有興趣的小夥伴來撩撩咱們~ web@talkmoney.cn 訪問 www.talkmoney.cn 瞭解更多