From systems thinking to systems doing 디자인 시스템을 생각하거나 공부할 때, 이걸 디자이너의 일이라고 생각하는 경향이 있는 것 같습니다. 디자인 시스템은 코드와 결합되어야 합니다. 마찬가지로 사업적인 부분과 관련이 없을 수 없습니다. 디자이너가 시스템을 이해하려면, 시스템 전반에 대한 접근 방식이 필요합니다. 이 글은 시스템을 구성하는 부품이 중요한 것이 아니라 시스템 구성요소의 관계에 대해 집중하라고 말합니다. 시스템 내의 모든 것은 연관되어 있어서 한 부분의 수정이 다른 부분까지 영향을 주기 때문입니다. 그래서 파괴 이론(Theory of Disruption)과 린 스타트업에 기반하여 다음을 구분하라고 합니다. - Entry points: 사용자는 어떻게 시스템에 접근하게 되는가? - Actions: 어떤 행동이 가능한가? 생성, 편집, 삭제는 어떻게 하는가? - Data: 신규 사용자는 데이터를 어떻게 입력하며, 기존 데이터는 어떻게 관리하는가? 복잡한 시스템을 조율하기 위해 Mental models과 Conceptual models 사이에 존재하는 지식 격차를 해결하면서 System models을 그려야 하는데, 이 때는 Narrative Object Models이 중요하다고 합니다. (이 부분은 이 키워드로 추가 검색이 필요할 듯합니다.) 그리고 문제를 풀려고 하지 말고, 문제 자체를 없애라는 조언도 합니다. 문제를 해결하려고 무언가 도입하면, 문제는 그대로 있고, 새로운 문제가 발생합니다. 그래서 미리 pre-mortem(제품 출시 전에 어떤 문제가 있을지 사전에 검토)과 특성요인 분석법(fishbone analysis, 수평적으로 현상과 결과에 대한 근본적인 원인과 이유를 시각적으로 분석ㆍ정리하는 분석기법)을 적용하는 것을 조언합니다.