Over the past few months, my design team at StreetEasy has started experimenting in adding a “design buddy” check-in to the final stages of the design process.

在過去的幾個月中，我在StreetEasy的設計團隊已開始嘗試在設計過程的最后階段添加“設計伙伴”簽到項 。

We were inspired by how engineers use pull requests in their workflows. For those unfamiliar, a pull request is a way for a developer to notify team members that they have completed a feature or update.

工程師如何在工作流程中使用拉取請求啟發了我們。 對于不熟悉的人，拉取請求是開發人員通知團隊成員他們已完成功能或更新的一種方法。

In addition to notifying, the pull request usually triggers a peer or manager review of the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. Once discussion is complete, the project maintainer will merge the feature into the official repository.

除了通知外，拉取請求通常還會觸發對等或管理員對提議功能的審查。 如果更改有任何問題，隊友可以在拉取請求中發布反饋，甚至可以通過推送后續提交來調整功能。 討論完成后，項目維護者將把功能合并到官方存儲庫中。

There are many benefits to this model. It makes for easier collaboration, clear documentation of decisions / updates, and important checks.

此模型有很多好處。 它使協作更容易，決策/更新的清晰文檔以及重要的檢查。

On our team, product designers have ownership in their individual product pods. While we welcome and seek out feedback from other designers on our individual pod work, we haven’t had this level of peer checks.

在我們的團隊中，產品設計師在各自的產品包中擁有所有權。 盡管我們歡迎并尋求其他設計師對我們的個人吊艙作品的反饋意見，但我們還沒有達到這一水平的同行檢查。

We started this process with the goal of ensuring quality and consistency of all designs being shipped. An extra design eye is always helpful to make sure all bases are covered!

我們開始這一過程的目的是確保所發貨的所有設計的質量和一致性 。 額外的設計眼總是有助于確保覆蓋所有底座！

這是我們實施“設計伙伴檢查”的方式 (Here’s how we implemented the “Design Buddy Check”)

When? As you finalize designs for implementation, reach out to your design buddy (everyone was assigned one person — we may switch every quarter to keep things fresh). After the design buddy check, you are cleared to hot-potato (AKA handoff) with engineers and make any contributions to our feature specs and design system.

什么時候？ 在最終確定要實施的設計時，請與您的設計伙伴聯系( 每個人都分配了一個人，我們可能每季度切換一次以保持最新狀態 )。 設計伙伴檢查后，您將與工程師通關進行熱土豆 (AKA交接)工作，并對我們的功能規格和設計系統做出任何貢獻。

How? In Covid-19 times, this is all done virtually. Share your Figma link with your buddy, and go through it together, using the checklist below. Compare the designs to our Style Guide. Note down new reusable components that could be added to our Design System (more on this process later).

怎么樣？ 在Covid-19時代，這一切都是虛擬完成的。 與您的好友共享Figma鏈接，并使用下面的清單一起進行瀏覽。 將設計與我們的風格指南進行比較。 記下可以添加到我們的設計系統中的新可重用組件( 稍后將在此過程中進行更多介紹 )。

The checklist below has been updated to remove any organization-specific checks. Thank you to Lisa Gorn for helping put this checklist together!

下面的清單已更新，以刪除所有組織特定的檢查。 感謝 Lisa Gorn 幫助將此清單合并在一起！

視覺效果 (Visual)

• Are you using brand colors exclusively?
  您是否僅使用品牌顏色？

• Is relative spacing to UI elements as base unit of 8 (if necessary, 4)?

  UI元素的相對間距是否為8的基本單位(如有必要，為4)？

• Does your relative spacing match the relative spacing of similar UI elements?
  您的相對間距是否與相似的UI元素的相對間距匹配？
• Are you using the right shadow criteria?
  您使用的陰影標準正確嗎？
• Does your icon choice communicate effectively?
  您選擇的圖標是否有效溝通？
• Is your icon the right size?
  您的圖標尺寸合適嗎？

一致性 (Consistency)

• Do interactions, icons that perform the same actions as others that already exist in the site or app?
  交互，圖標執行的功能與網站或應用程序中已經存在的其他圖標一樣嗎？
• Are you using the appropriate sizes and elements for desktop vs. mobile web vs. app?
  您是否針對臺式機，移動網絡和應用程序使用了適當的大小和元素？

• Are you using our existing controlled vocabulary for similar actions?

  您是否正在使用我們現有的受控詞匯表執行類似操作？

  Are you using our existing controlled vocabulary for similar actions?(e.g. close vs. cancel, back vs. go back, view vs. see)

  您是否正在使用我們現有的受控詞匯表執行類似操作？ (例如，關閉與取消，返回與返回，查看與查看)

• Are existing patterns being used for similar actions/items?

  現有模式是否用于類似的動作/項目？

  Are existing patterns being used for similar actions/items?(e.g. text link vs. secondary button, back arrow vs. back link, tooltip vs. exposed helper copy)

  現有模式是否用于類似的動作/項目？ (例如，文本鏈接與輔助按鈕，后退箭頭與后退鏈接，工具提示與公開的幫助程序副本)

• Are you using existing elements / components where appropriate?
  您是否在適當的地方使用現有的元素/組件？

• Is your icon placement relative to text appropriate?

  您相對于文字的圖標位置合適嗎？

  Is your icon placement relative to text appropriate?(e.g. left vs. right, case dependent)

  您相對于文字的圖標位置合適嗎？ (例如，左與右，視情況而定)

相互作用 (Interaction)

• Are all states accounted for?

  是否所有州都入帳？

  Are all states accounted for?(e.g. default, touch, hover, disabled, etc)

  是否所有州都入帳？ (例如，默認，觸摸，懸停，禁用等)

• Are animation curves and durations for enter, exit, and state change defined?
  是否定義了進入，退出和狀態更改的動畫曲線和持續時間？

版式 (Typography)

• Are you using our typography library?
  您在使用我們的排版庫嗎？
• Are you using heading, body, eyebrow, and helper copy styles correctly?
  您是否正確使用了標題，身體，眉毛和輔助復制樣式？
• Are you using the right colors for the type style that you have chosen?
  您是否為所選的字體樣式使用了正確的顏色？

層次結構 (Hierarchy)

• Do the most important UI elements take priority?
  最重要的UI元素優先嗎？
• Are you using the correct type elements to communicate hierarchy?
  您是否使用正確的類型元素來傳達層次結構？

案例 (Cases)

• What happens to text when it gets too long?

  文本過長會如何處理？

  What happens to text when it gets too long?(e.g. truncation, wrapping, etc)

  文本過長會如何處理？ (例如，截斷，換行等)

• Are empty states accounted for?
  空國家占了嗎？
• Are error states accounted for?
  是否考慮了錯誤狀態？
• Are loading states accounted for?
  是否考慮了加載狀態？

輔助功能最佳做法 (Accessibility Best Practices)

• Ensure the color contrast of text is accessible.

  確保可以訪問文本的顏色對比度。

• Write good alt text for your images. (place in annotations for the engineers)

  為您的圖像寫一個好的替代文本 。 (為工程師添加注釋)

• Don’t indicate important information using color alone. Pair messages with an icon.
  不要僅使用顏色來表示重要信息。 將消息與圖標配對。
• Don’t indicate state changes using color alone.
  不要僅使用顏色來指示狀態變化。
• Always design focus states to help users navigate and understand where they are. At minimum, consider using browser defaults for focus states.
  始終設計焦點狀態以幫助用戶導航并了解他們的位置。 至少應考慮將瀏覽器默認值用于焦點狀態。
• Help users understand inputs, and help them avoid and correct mistakes.
  幫助用戶理解輸入，并幫助他們避免和糾正錯誤。
• If an experience cannot be made accessible, create another route for users to get that information.
  如果無法獲得一種體驗，請為用戶創建另一條途徑以獲取該信息。
• Place secondary actions inside of menus (or non-modal dialogs), and don’t use hover states to hide the trigger.
  將輔助操作放置在菜單(或非模式對話框)中，并且不要使用懸停狀態隱藏觸發器。

—

-

And that’s it! Let me know your thoughts.

就是這樣！ 讓我知道你的想法。

Do you do a similar quality check in your organization? Are we missing anything in the checklist?

您是否在組織中進行過類似的質量檢查？ 我們在清單中遺漏了什么嗎？