디자인 시스템의 성공과 실패에 대한 6가지 질문
(uxdesign.cc)요즘 디자인시스템 초기 설계에 참여하면서 고민이 많습니다.
관련해서 저번주 UX Collective 본 내용인데요. 회사내 디자인 시스템 멤버들을 위해 번역했는데 아까워서 여기도 공유해봅니다.
디자인 시스템을 다루는 10명의 디자이너를 인터뷰해서 요약한 내용이라고 해요.
질문 1. DS 역할에서 실패하려면?:
- 경찰이 되기
- 디자이너의 힘을 쓰기 (정치 얘기)
- 구성요소를 통합 해놓고 사용하진 않기
- 팀의 요구사항을 예측하는 대신 사후대응 하듯이 작업하기
- 사용자(다른 디자이너나 개발자)의 목소리를 듣거나 조사하지 않기
- DS를 위해 만든 DS
- 작업의 명확한 로드맵과 프로세스를 유지하지 않기
- 실현 불가능한 이상적인 경험 만들기
- 팀과 함께 테스트 하지 않는 것
- DS를 하나의 제품으로 이해하지 않는 것
- 도구를 만들고 사람들에게 사용하는 법을 교육하지 않기
- 실제 일하는 방식에서 벗어난 이론을 너무 많이 가져오기
- 혼자 할 수 있다고 생각하기
- 기술팀의 누군가와 지식교환에 100% 집중하지 않기
- 너무 유연하지 못한 컴포넌트를 만들고 Detaching 허용하지 않기
- 도움을 요청하지도 않고 사람들과 연결되지 않기 (내부던 외부던)
- 바로 옆이 아닌 멀리서 규칙을 지시하기
질문 2. DS가 성공하려면 필요한 소프트스킬에는 어떤 것들이 있을까요?
- 커뮤니케이션, 커뮤니케이션, 커뮤니케이션!!!
- 사용자와 함께하기, 듣고 묻고 조사하는게 정말 중요합니다.
- 실패를 겸손하게 인정하세요
- 인내심을 가지세요
- 안전한 공간을 만드는 능력
- 가르쳐주기
- 재사용 방법에 대한 체계적인 비전 제시
- 확장에도 단호하게 일관성을 유지해야합니다
- 상대방을 이해 할 때 그렇게 많이 이입할 필요는 없습니다. 규칙을 있는 그대로 받아들이세요.
- 95%는 하드스킬이고 5%는 규칙에 어긋났을 때를 위한 소프트스킬입니다.
- 사람들의 성장을 독려하고 공유하세요
- 자율성
- 계속 제품(DS)을 파세요
- 전략적으로 생각하세요
- 모든 사람들이 참여하게 하세요
- DS와 관련된 소음 내기
- 가능한 많은 시나리오를 알아내기위해 가능한 많은 시간을 쏟으세요
- 언어를 맞추세요.
질문 3. DS가 수행되는 방식이 더 중앙집중적이여야 합니까 아니면 더 분산되어야 합니까?
두가지 방식이 있는데 있는데 사람들이 어떻게 디자인을 하는지 확인하고 책임지는 중앙집중식 팀과, 모든 사람이 그것을 책임지게 하는 방식입니다. 어느쪽을 선택하는게 맞을지 사람들에게 물어봤습니다.
- 우리는 너무 중앙집중적인 팀이라 병목이 발생합니다. 하지만 분산모델은 오너십 약화 문제가 있을수도 있습니다.
- 우리는 DS를 집중화하기 위한 100명 이상이 모여있는 디자이너 팀이 있습니다.
- 사람들이 만드는 알파 라이브러리들과 협력하고 거기서 DS 팀의 백로그를 만듭니다.
- 사람들이 자발적으로 컴포넌트를 만들도록 교육합니다.
- 중앙집중화할지 여부는 다분히 정치적인 문제입니다. 그것을 결정하기 전에 얼마나 확장성있어야 할지에 대해서 정확히 알아야합니다.
- 기대치를 조정하고 DS 만들기에 사람들을 참여시켜야합니다.
- 협업하길 원했지만, 그 방법을 잘 몰라서 프로세스를 만들었습니다. (Culture vs Process)
- 처음엔 전달을 위해 다소 덜 협력적일 수 있습니다. 성숙해지면 더 협력적으로 만들 수 있습니다.
- 우리는 이제 그걸 탈중앙화해야 하는 시기에 도달했습니다; 사람들에게 기여하는 방법을 가르쳐야합니다.
- 당신이 사람들을 교육하지 않는다면 사람들은 기여하지 않을것입니다.
- 디자이너가 표준을 넘어서서 더 나은 결과물을 만들고 싶어할 때, 동시에 그것을 표준화하는 방법을 같이 생각할 수 있어야합니다.
- DS 는 1~2명이서 할 수 없습니다. 시스템을 만드는 것이기 때문에 DS는 스쿼드 단위에서 시작되어야 합니다.
- 팀 규모에 따라 매우 다르며 때로는 DS 팀은 코어 컴포넌트 개발에 집중하고 다른 앰버서더들이 그것을 전파시킬 수 있습니다.
-최종적으로 우리는 중앙집중식 팀이지만 앰버서더들과 협력적으로 일합니다. 최종결정은 DS 팀에서 합니다.
4. DS가 더 자세하고 제한적으로 만들기 위한 규칙이라고 생각합니까? 아니면 더 광범위하고 디자이너가 새 레이아웃을 만들게 자유를 주는 개방적인 것이라고 생각합니까?
폐쇄냐 개방이냐? 만약 디자인시스템 일을 하신다면 이 질문에 관심이 있을겁니다. 나도 그렇기에 사람들에게 물어보기로 했습니다.
- "접근성"에 대한 것은 더 제한적으로 접근하세요
- 우리는 다같이 기본적인 구조에서 시작했지만, 몇가지 비일관성을 만들기 시작했습니다. 따라서 우리는 100% 폐쇄적이지는 않지만 좀 더 제약사항을 두기로 했습니다. 그러면서도 디자이너에게 뭔가 되돌려 줄 수 있는 방법을 찾으려고 항상 노력합니다
- 상황에 따라 다르므로 리스크를 먼저 측정하고 결정하세요. 일반적으로 더 작은 팀 = 높은 유연성
- 그저 창의적이고 새로운 구성요소를 만드는 일이 아닙니다. 사람들의 요구에 맞출 수 있도록 충분히 유연한 컴포넌트가 필요합니다
- DS는 비즈니스입니다. 컴포넌트가 적을 수록 좋습니다.
- 사람들이 DS를 사용하기를 즐겨야합니다. 겉으로보기엔 유니폼같아서 유연성이 없어도 된다고 생각하기 쉽습니다만 (그렇지 않습니다)
- 처음부터 매우 제한적일 수는 없습니다. 시간이 충분히 지남에 따라 특정 패턴 등으로 진화를 시작할 수 있습니다.
- 회사에 새로 합류하는 디자이너에게는 더 많은 제약이 도움이 될수도 있습니다. 규칙을 깨기 위해선 규칙부터 시작해야합니다.
- 우리는 사람들이 그들만의 레시피를 만들 수 있도록 충분한 재료를 제공합니다.
- 팀의 성숙도에 따라 다릅니다. 주니어가 더 많다면 더 적은 문서를 이해하기 때문에 더 많은 디자인 지침을 요청하는 경향이 있습니다. 그래서 더 많은 교육이 필요해지지만 그래도 그들을 가두지 않고 자유롭게 일할 수 있게 하도록 노력합니다. 가장 큰 챌린지는 사람들이 문서를 직접 읽고 사용하도록 만드는것이므로 Figma 처럼 디자이너에게 더 가까운 곳으로 가져갈 가능성이 있습니다.
- 접근성과 미학에 대한 것이라면 더 제한적이여야합니다.
- 토큰들은 일관성을 지키는데 중요합니다.
- 좋은 문서는 사람들과 조화를 이루는 것과 자유롭게 두는 것 사이의 밸런스를 맞춥니다.
질문 5. 브랜딩과 마케팅에 연결된 DS에 대해 어떻게 생각하십니까?
(잘 모르는 분야라 번역이 좀 어렵네요)
디자인 시스템이 결국 디지털 제품에 대한 것이여야 한다는 걸 이해하지만, 제품은 가장 중요한 브랜드 플랫폼 중 하나일 수 있기 때문에 사람들이 그것을 어떻게 연결지어 생각하는지 궁금했습니다.
- DS에 연결된 브랜딩에 대해 생각하는 법은 그게 반대로 DS에 어떻게 영향을 끼치는지 생각해보는 것입니다.
- 우리는 브랜드의 모양과 느낌을 정렬하기 위해 디자인 시스템을 브랜드에 맞추기 시작했습니다.
- DS는 확장성과 브랜드 ID 를 위한 것이지만, 이 둘 사이의 연결은 브랜딩 팀에 따라 다릅니다.
- Since DS is a language, MKT could support with assets for it;
- 브랜딩 팀은 기본 규칙을 만들기 위해 처음부터 DS 에 합류해야 합니다.
- 회사에 따라 다릅니다. DS 는 브랜드를 강화하는 도구이기 때문에 정렬을 맞추는 것은 중요합니다. 두 영역간의 연결은 DS의 접근성에도 영향을 끼칩니다.
- 전략을 조정하기 위해 브랜딩 팀과 싱크를 맞춘 방법을 찾는것이 중요합니다.
- They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;
- 때로는 문서와 시스템을 함께 사용할 수 있지만, 대체로는 그렇지 않습니다. DS는 인터페이스입니다. 브랜드 팀은 따로 "브랜딩 시스템"을 갖고 있고 라이브러리끼리 상호작용하는 경우가 더 일반적입니다. 그 둘은 완전히 동일하진 않습니다.
질문 6. DS의 성공을 어떻게 측정할 수 있습니까?
- 참여, 채택 및 팀 상태를 이해하기 위한 인식 조사
- 컴포넌트 커버리지 (DS가 얼마나 쓰이는지 vs 하드코딩 되어있는지)
- Adoption
- Time to market
- ROI
- Figma Analytics
- 개발팀들의 반응
- 접근성
- 구성요소가 사용된 횟수