1，這本書討論了如何系統地推進設計過程，如何圍繞具體的產品目標和團隊特征構建設計體系。
2.設計系統由各種模式、組織結構、團隊文化、產品類型和設計流程組成，其中設計模式是我們要探討的重點內容。
3.設計模式不是設計規範。傳統的設計規範是字體、顏色、圖標等的定義，更側重於風格。設計模式是指任何可重用的接口組件。按照便宜大叔的理解，模式不是抽象的，而是妳具體的業務和產品。比如登錄註冊，每個產品都有，但是妳的產品可能因為某種原因註冊的時候要提交頭像，那麽妳就可以基於妳的產品建立壹個註冊模式。
我相信很多人都和摳門大叔壹樣，為公司做了設計規範。翻翻之前的歷史，從1.0.0到今年的4.0.0，壹共四次叠代，但其實變化大的只是兩個版本。第壹版成立時，吉焦叔叔是助手，主要由公司的壹名設計師制作。她用ps建立了公司的第壹版設計規範。當時只有兩三個人。看壹看，記下幾個關鍵的顏色值就行了。規格問題也很明顯:
1.基本規範只適用於閱讀，不能直接訪問。
2.規範中控件、組件和零件混雜在壹起，組件經常根據業務變化，導致規範變化頻繁。
3.整個規範不利於合作、維護和叠代，但由於當時只有兩三個人，這個問題並不明顯。
所以在2.0.0版本中，便宜大叔根據使用情況優化了幾點:1，將文檔與草圖源文件分離，允許文檔查看，草圖源文件直接使用；2.將基本控制與業務控制分開。所謂基礎控件就是系統控件，比如彈出、吐司，業務控件就是基於業務場景沈澱的控件；3.添加修訂記錄。現在來看，也有問題:
1，修改起來比較麻煩，需要更新兩個文件才能改壹個地方；
2.協同工作效率差，需要通知其他人更新，否則信息不對等；
3.業務控件越來越多，幾乎各種場景風格都有。？
這些是熟悉的設計規範嗎？字體、顏色、圖標、控件等的標準化。基本上是壹個設計團隊的所有標準。我們定義的基礎控件無非就是過濾iOS和材質設計的控件。後來螞蟻設計出來後，我們意識到有些頁面是Web的，結果我們的基礎控件只是在三個平臺之間尋求壹個平衡，稍微定義壹下，讓它更符合我們的產品需求。
我們在設計什麽？
其實2.0.0版本中做的業務控制，就是有意識地總結壹些設計時已經做過的頁面，讓妳不用在同壹個問題上反復思考解決方案。模式庫存的意義也是壹樣的。我們的產品有四五十個功能，六個設計師同時在不同的功能上設計。誰能保證設計出壹個大家都能設計的壹模壹樣的信息展示頁面？但是，雖然信息展示頁面可能面對的商家不壹樣，但是設計的不可以壹樣嗎？書中說，相同的信息架構和相同的功能都可以歸入相同的設計模式。雖然在不同的業務場景中可能會有不同的外觀需求和行為，但這只是模式的變體，而不是不同的模式。
我粗略的收集了壹些列表頁面。當然，列表只是它們的表達式。而他們的目的就是展示類似於社區公告牌的信息。根據我在書中寫的內容，我將頁面按功能分類，分解其信息架構，並給這個模型取了壹個好記的名字“窗口列表”，如下:
為什麽叫窗口列表？名字在書裏寫明了。它應該易於記憶並與功能相關聯。與列表1和列表2相比，窗口列表顯然更容易記憶。
所以回到最初的問題:我們在設計什麽？
摳門大叔認為我們應該了解真正的需求。設計不僅僅是為了解決問題，更要看到真正的問題。就像大廠喜歡動不動就建壹個大而全的功能控制庫，其實在壹定程度上減少了不必要的重復工作，我們更應該註重了解用戶和需求。
我們是什麽樣的團隊？
什麽樣的團隊和組織結構實際上影響了我們的設計體系。具體體現在設計制度的三個方面:實用規則(嚴與松)；建設模式(模塊化、集成化)；管理機制(集中式、分布式)。(譯文摘自譯者C7210，附鏈接。後來，書中引用了Airbnb、ted和Future Learn的例子。
這個摳門大叔很有洞察力。當初建立規範的時候，有團隊成員擔心規範太細，會影響設計師的發揮。但是書中這壹章寫的很清楚，最終目的是為產品服務，包括團隊的風格建設。我們可以根據自己的需求，量身定制屬於我們團隊的設計體系。
其實還有很多小點沒寫下來，因為怕文章太長太啰嗦，剩下的就看大家自己看了。我只寫了我認為最重要的東西。感謝您的閱讀。
翻譯版本鏈接:
/s？_ _ biz = mjm 5 MDC 0 mdiyma = = & amp；mid=2650619728。idx=1。sn = 292 caed 44 c 7 f 985 ca 52 ab 0 c 18f 357 c 7 f & amp；chksm = be 49 a4c 3893 e 2 DD 57d 13 f 23 A8 d 0 cdecb 28 ab 3 e 2 c 67 b 37 b 894628 E4 e 7670 CDB 263 b 0 e 98187 CBC & amp；MP share = 1 & amp；場景= 23 & ampsrc id = 1219 scj 6 pdpxjkdz 68 x 1 pt9o % 23日