요약: DesignOps 팀의 구조는 팀의 특정 과제와 요구로부터 출발해야 합니다. 이러한 팀 구조는 DesignOps 팀을 지원할 수 있는 다양한 접근 방식을 보여줍니다.
DesignOps는 일관되고 품질 높은 디자인을 가능하게 하는 것과 관련된 많은 요소들이 있기 때문에 광대한 기회를 가지고 있습니다. 조직이 DesignOps 실무에서 중점을 두는 것은 해당 조직의 요구와 목표가 반영된 것이어야 하며, 또한 DesignOps 팀이나 역할에 대한 해당 실무 구조도 반영해야 합니다.
이 기사에서는 DesignOps 팀의 일반적인 5가지 유형의 구조에 대해 설명합니다. 적합한 구조는 회사마다 정형화된 DesignOps 프로그램에 대한 전반적인 조직 구조, 목표 및 요구 수준에 따라 달라지며, 따라서 어디에나 잘 맞는 최고의 구조는 없습니다. 이러한 구조는 DesignOps 성숙도 모델에서 필수적이거나 점진적인 단계가 아니라 서로 다른 상황에 적합한 잠재적 모델로 보아야한다. 일부 조직은 확장됨에 따라 이러한 구조 변화를 자연스럽게 경험할 수 있지만, 팀은 적절한 지원과 리소스를 제공하는 구조 이외의 다른 구조를 목표로 할 필요가 없다.
일반적인 5개 유형의 DesignOps 구조:
- Scattered(산발형): DesignOps의 노력은 일상적인 업무 책임의 일부로 다른 역할(예, 디자인 매니저)에 의해 수행된다. 조직 내에서 “DesignOps”는 용어로 사용되지 않고 형식화 된 개념으로 알려지지 않았을 가능성이 큼
- Solitary(단독형): 1명으로 구성된 DesignOps 팀. 이 전담 DesignOps 역할은 초기에 반응적인 방식으로 디자인 팀의 가장 큰 문제점을 식별하고 프로그램을 개발
- Specialized(전문형): 풀 타임으로 DesignOps의 특정 측면을 관리하거나 감독하는 소수의 사람들로 나뉘어진 형태
- Distributed(분산형): 팀 간 조정에 중점을 두고 조직 전체에 걸쳐 개별 팀에 분산되어 있는 형태
- Elevated(향상형): 전체 디자인 조직에 영향을 미치고 혜택을 주는 중앙 집중식 리소스와 프로그램을 제공하여 별도의 독립체로 확장된 형태
Type 1: Scattered(산발형)
DesignOps가 흩어져 있으면 많은 사람들이 DesignOps와 관련된 활동을 하지만 공식적인 관행이나 직함이 존재하지 않습니다. 많은 조직에서 “DesignOps”라는 용어를 들어본 적이 없거나 설명하는 내용을 이해하는 사람이 아무도 없을 것입니다. “DesignOps”라는 용어는 확실히 모든 조직에서 일상적으로 사용하는 용어가 아니며 대부분의 조직에는 정형화된 DesignOps역할 (즉, DesignOps에 전담하는 직원들)이 없습니다. (실제로 조사에 따르면 DesignOps의 리드 또는 매니저가 있는 팀은 13%에 불과했습니다.)
그러나 공식화된 DesignOps 관행과 역할이 없는 조직에서도 여전히 디자인 팀 및 프로세스와 관련된 운영상의 문제를 파악하고 해결하려는 사람들이 있습니다. 아마 그렇게 레이블을 붙이지 않아도 공식적으로 인정된 다른 직무와 함께 DesignOps 유형의 작업을 수행하는 상급 수준의 디자이너, 리드 및 관리자가 있을 수 있습니다.
이 산발형 구조는 조직 전반에 걸쳐 DesignOps 성숙도가 낮다면 널리 퍼질 가능성이 있습니다. 557명의 UX 전문가를 대상으로 조직의 DesignOps 성숙도 수준을 조사했을 때, 응답자의 10%만이 팀 전반에 걸쳐 DesignOps에 대한 폭넓은 이해가 있거나 회사 문화 내에서 DesignOps의 가치가 확립되었다고 보고했습니다.
산발형 구조의 실천 아이디어
공식화된 DesignOps가 없다는 것은 전반적인 UX 성숙도가 낮음을 나타낼 수 있습니다. 확실히, UX의 가치를 인정하지 않거나 전반적인 UX 관행을 지원하지 않는 회사는 공식화된 DesignOps 관행을 지원하지 않거나 전담 DesignOps 전문가를 고용하지 않을 것입니다. 이러한 경우 디자인 책임자와 관리자는 운영상의 문제를 해결하고 디자인 작업을 하기 위해 시간과 자원을 허비하며, 이러한 노력에 대한 인식 없이 스스로에게 추가적인 부담을 주는 경우가 많습니다
산발형 DesignOps 구조는 DesignOps를 이해하고 가치를 알고 있는 구조에도 존재할 수 있습니다. DesignOps 여정의 초기에 있는 경우, 전담 DesignOps 역할에 대한 리소스가 없을 수도 있습니다. 이러한 역할이 널리 요구되는 경우에도 마찬가지입니다. 이러한 상황에서 팀은 작업 설명에 운영 관련 책임과 기존 디자인 역할의 책임을 포함하기로 결정할 수 있습니다. 예를 들어 디자인 매니저는 팀을 위한 방법론을 작성할 수 있는 권한과 리소스를 받을 수 있습니다. 또는 대표 디자이너로 구성된 위원회가 디자인 시스템 생성, 디자인 프로세스 문서화 또는 UX 회의 체계화와 같은 특정 DesignOps 과제를 수행할 수 있습니다.
산발형 구조의 도전 과제와 이점
통합된 DesignOps 구조가 없는 개별 팀은 도구와 방법을 자율적으로 선택하는 이점이 있지만 가장 큰 문제는 종종 일관성이 부족할 수 있다는 것입니다. 개별 팀이 정렬되지 않으면 프로세스, 방법 및 도구 스택이 광범위하게 변형되어 협업, 통찰력 및 템플릿 공유, 중복 작업 방지를 어렵게 할 수 있습니다.
Type 2: Solitary(단독형)
단독형 구조에서는 한 사람이 DesignOps에 풀타임으로 전념할 수 있독 인정과 권한을 부여받습니다. 이 사람은 종종 DesignOps 책임자, DesignOps 관리자와 같은 직함을 가지고 있으며 DesignOps 창의 끝이 되어 미지의 영역을 통해 길을 개척하고 팀을 DesignOps 개척지로 이끄는 역할을 합니다.
이 DesignOps 팀은 일반적으로 필요에 따른 피해 통제에 중점을 두고 운영 부채의 잔고를 파악하고 가장 명백한 문제점을 한 번에 하나씩 해결합니다. 이 역할은 여러 설계자 또는 설계 팀에서 작동하여 가장 큰 운영상의 문제를 식별하고 모든 팀에 도움이 되는 일관성과 표준을 개발합니다.
종종 이 역할은 두 가지 주요 책임으로 나뉩니다. 디자인팀 연결, 팀 전체의 문제를 경청하고 종합하는 부분과 고충을 완화하고 디자이너를 더 잘 지원하는 접근 방식과 프로세스를 설계하는 부분입니다.
단독형 구조의 실천 아이디어
단독형 구조는 시간순으로 산발형 구조에서부터 오는 경우가 많습니다. 왜냐하면 결국 산발형 구조의 누군가가 개별 디자이너나 팀 전체의 불일치와 비효율성을 인식하고 이 문제를 해결하기 위해 모두 모여야한다는걸 제기하기 때문입니다.
규모가 2배 또는 3배로 빠르게 확장되는 작은 팀(디자이너 10명 미만)의 경우 기존 디자이너는 성장하는 팀 전체에서 프로세스와 협업을 유지하기가 점점 어려워지고 있음을 인식할 수 있습니다. 이 사람은 고통을 직접 느끼고 이러한 운영 문제를 해결하기 위해 경영진에게 사례를 제시하여 최초의 공식화된 DesignOps 역할을 만듭니다.
또는 회사가 일반적으로 잘 조정된 여러 팀에서 비교적 높은 수준의 UX 성숙도를 가지고 있다면, 경영진은 공식화된 DesignOps의 필요성을 사전에 인식하고 노련한 DesignOps 전문가를 불러들여 조직에서 DesignOps를 "설립"할 수 있습니다.
단독형 구조의 도전과제와 이점
단독형 구조에서 DesignOps는 공식적으로 인정받고 있습니다. 디자인 프로세스를 최적화하고 적어도 한 사람이 이 작업을 풀타임으로 맡을 수 있도록 하기 위해 일정 수준의 공식적인 승인과 동의가 있습니다. 그러나 이 사람은 해결해야 할 과도한 운영상의 문제와 이를 수행하는 데 필요한 많은 활동(예: 장애물 식별, 로드맵 활동, 추적을 위한 노력, 피드백 수집, 진화하려는 노력)에 빠르게 압도당할 수 있습니다. 이런 부하는 기존 디자이너가 풀타임으로DesignOps에 집중하기 전에 이것의 성공을 입증해야 하는 경우 악화됩니다.
게다가 이 새로운 역할은 불안정한 위치에 있습니다. 그들은 DesignOps 옹호하고 전파하려는 노력을 수행하며 이해 관계자와 변화를 수용하지 않으려는 다른 디자이너들의 저항에 직면할 수 있습니다. 단독형 구조에서 프로세스를 설계하고 적용하려는 DesignOps 전문가는 디자이너 시스템에서 거부되기 쉽기 때문에 경청 및 관계 구축 기술(이전 디자인 역할에서 온 사람에게는 더 쉬움)이 중요합니다.
Type 3: Specialized
전문형 DesignOps 구조에는 각각 특정 프로그램이나 전문 영역에 중점을 둔 여러 개의(제한된) 전용 DesignOps 역할이 있습니다. 모든 종류의 DesignOps 과제(예: 단독형 구조)를 식별하고 해결하는 데 중점을 두는 단일 DesignOps 제너럴리스트가 아니라 전문화되어 있습니다.
이 구조 내의 개별 DesignOps 전문가는 각자의 전문 지식 및 기술 영역에 맞춰진 운영상의 문제와 솔루션에 중점을 두지만, 서로 긴밀하게 협력하여 디자이너를 지원하기 위해 마련된 운영 프로그램이 상호 보완적이고 조정될 수 있도록 협력합니다.
이 구조 내에서 DesignOps의 역할은 전문화된 필요 영역이 분명해진 후에 생성되며 종종 단독형 구조에서 과중한 역할을 완화하여 각 사람이 가장 동기 부여를 받고 가장 잘 알고 있는 영역에 집중할 수 있도록 합니다.
전문형 구조에서의 실행 아이디어
DesignOps가 추진력을 얻고 시간이 지남에 따라 어느 정도 측정 가능한 성공을 입증함에 따라 단일 역할이 처리하기에는 너무 많아질 수 있습니다. 한 명의 슈퍼휴먼이 DesignOps의 여러 영역을 장기적으로, 전문적으로 관리할 수 있다고 해도 다루어야 하는 DesignOps의 모든 잠재적 영역에 관심이 없거나 능숙하지 않을 수도 있습니다.
DesignOps 팀이 초기 DesignOps 노력을 성공적으로 마친다면 종종 추가 DesignOps 역할에 대한 동의를 얻을 수 있습니다. 여기에서 DesignOps 팀은 가장 영향력 있는 것으로 입증된 DesignOps의 특정 프로그램 또는 전문적인 측면에 집중할 수 있는 추가 전담 역할(시작할 사람이 한두 명일 수도 있음)을 추가하여 확장하게 됩니다.
예를 들어, 새롭게 부상하는 소규모 전문 구조에는 3명의 DesignOps 전문가가 있을 수 있습니다. 하나는 고용 및 온보딩과 같은 PeopleOps 이니셔티브에 집중하고, 다른 하나는 디자인 워크플로 최적화에 집중하고, 다른 하나는 도구 큐레이션, 라이선스 및 도구 온보딩에 중점을 둡니다.
전문형 구조의 도전 과제와 이점
전문형 구조에서 개별 DesignOps 전문가는 특정 작업 흐름에 집중하여 디자인 조직의 장기적 성공에 중요한 것으로 확인된 영역에 전념할 수 있습니다. 그러나 이러한 역할 간의 강력한 정렬이 없으면 DesignOps는 단편화될 것입니다.
또한, 성장하는 DesignOps 팀은 다른 사람들이 자신의 역할을 이해하도록 알리는 책임을 게을리해서는 안 됩니다. DesignOps가 제공하는 차별화된 가치에 대해 명확하게 제공해야 합니다. 또한 조직 내 다른 운영 역할(예: PeopleOps, MarketingOps, DevOps, BusinessOps 등)과 파트너십을 구축하여 모든 사람이 자신의 노력, 목표 및 커뮤니케이션에 동기화되도록 시간과 노력을 투자해야 합니다.
Type 4: Distributed(분산형)
분산형 구조에서 DesignOps 전문가는 조직 전체의 개별 디자인 팀에 전담적인 지원을 제공합니다. 이러한 DesignOps 역할은 그들이 지원하는 개별 팀의 일부이며 워크플로 관리, 디자인 목표 설정, 프로젝트 궤적 모니터링 또는 로드맵 작성과 같은 영역을 수행할 수 있습니다.
이상적으로는 이러한 DesignOps 역할이 함께 작동하여 전체 전략과 커뮤니케이션이 모든 팀에서 동기화됩니다. 모든 분산된 팀 구조와 마찬가지로 분산된 팀 구성원이 서로 공유하고 협업할 수 있는 시간을 제공하는 접점(예: 회의)이 설정되어야 합니다.
분산형 구조의 실천 아이디어
이 구조는 높은 수준의 확장을 경험하거나 팀이 널리 분산되어 있는 디자인 팀에 일반적입니다. 디자인 팀의 규모가 계속 커지면서 단 하나(또는 제한된 수)의 DesignOps 역할이 변화하는 요구와 과제를 따라잡기가 어려워질 수 있습니다. DesignOps는 디자인 조직의 상태를 더 잘 모니터링하고 최적화하기 위해 더 많이 실무에 발을 붙이고 있어야할 필요가 있습니다. 이 경우 전담 디자인 제작자 또는 디자인 프로그램 관리자가 일상적인 디 자인장프로로에서 장애물을 제거하는 데 도움을 줄 수 있습니다.
DesignOps을 전담하는 역할은 일반적으로 제너럴리스트이지만 항상 그런 것은 아닙니다. 예를 들어 빠르게 성장하는 팀은 전담 채용 및 온보딩에 전담하는 역할을 고용할 수도 있습니다.
분산형 구조의 도전 과제와 이점
이 접근 방식은 유연하며 모든 팀이 DesignOps의 지원을 받을지 여부를 선택할 수 있기 때문에 팀이 DesignOps에 대한 다양한 수준의 요구사항이나 수용 수준을 가지고 있는 조직에서 잘 작동합니다. 따라서 아직 그러한 역할의 필요성을 인식하지 못하는 팀에 "강제"할 수 없습니다.
추가로, 전담 DesignOps 지원을 통해 개별 팀의 요구 사항과 피드백을 더 잘 이해할 수 있습니다. DesignOps 역할이 전체 디자인의 정렬을 만들기 위한 건전한 구조를 가지고 있는 경우, 분산된 팀은 지식을 공유하고 일관된 프로세스를 가질 가능성이 높습니다.
그러나 전담 DesignOps 역할이 어디에 초점을 맞춰야 하는지 알기 어려울 수 있습니다. 개별 팀 프로젝트를 지원하는 데 더 많은 노력을 기울여야 하는가, 전반적인 UX 프로그램 및 프로세스를 최적화하는 데 더 많은 노력을 기울여야 하는가? 이 시점에서 전반적인 전략과 접근 방식을 주도하고 이 분산된 팀을 조정하기 위해 강력한 DesignOps 리더십이 필요합니다.
Type 5: Elevated
향상형 구조에서 DesignOps는 그 자체로 전체 디자인 조직을 지원하는 고급 도구와 프로그램을 만드는 데 중점을 둔 조직입니다.
여기에서 DesignOps와 디자인은 별개의 팀이지만 서로 일치된 구조와 목표가 있습니다. 이 구조는 팀 간 정렬이 최적화되고 안정화되어 일부 DesignOps 역할이 보다 전략적으로 될 수 있도록 할 때 발생합니다. 이 접근 방식에서 DesignOps의 역할은 글로벌 이니셔티브에 초점을 맞추는 경향이 있으며 디자인 팀과 해당 프로세스를 사전에 활성화하는 디자인 전반의 리소스를 생성하며 일상적인 디자인 활동 및 프로젝트 일정에서 더 많이 제거됩니다.
이 구조에서 DesignOps는 조직 내 다른 부서의 리더십 역할과 유사한 역할을 가진 강력한 리더십이 필요합니다. DesignOps는 전략 수립의 일부이며 최고의 디자인을 제공하고 건강한 팀과 문화를 유지하기 위한 중요한 구성 요소로 간주됩니다.
향상형 구조의 실천 아이디어
일부 고급 DesignOps 팀은 개별 디자이너의 작업에서 공유 시스템(예: 디자인 시스템 또는 리서치 저장소)을 만들고 유지 관리하는 부담을 제거하도록 돕습니다. 이러한 DesignOps 팀에는 공유 시스템에서 풀타임으로 작업하는 자체 디자이너와 개발자가 있을 수도 있습니다.
중앙 집중식 DesignOps 팀에는 분산형 구조가 수반될 수 있습니다. 여기서 DesignOps 역할의 한 그룹은 개별 팀에 직접 전담되고 한 그룹은 문화 구축, 신신규 고용 경험 또는 커리어 패스웨이에 중점을둔 중앙 집중식입니다.
향상형 구조의 도전 과제와 이점
전담팀 구성원이 중앙 집중식 도구 및 프로그램에 대해 풀타임으로 작업하므로 이러한 이니셔티브는 유용하고 액세스 가능하도록 적절한 주의를 기울이고 디자이너는 이중 책임에 의해 방해받지 않고 디자인 작업에 집중할 수 있습니다. 그러나 DesignOps 팀은 계속해서 디자인 팀 피드백을 수집하고 이에 따라 조치를 취해야 합니다. 그렇지 않으면 관련이 없거나 쓸모없는 프로세스와 도구가 위에서 아래로 강요된다고 느끼는 팀이 경멸하게될 위험이 있습니다.
이 접근 방식에는 이니셔티브의 우선 순위를 지정하고 시간이 지남에 따라 DesignOps를 확장할 계획을 세우는 강력한 리더십이 필요합니다. 일부 역할은 DesignOps 목표에 대한 진행 상황을 평가하고, 비즈니스 요구 사항이 변경됨에 따라 DesignOps의 초점 영역을 발전시키고, 조직의 다른 부서와 평행하도록 DesignOps 리더십 및 영향력을 높이는 것과 같은 프로그램을 만드는 것에 대해 생각해야 합니다.
결론
조직에서 사용하는 DesignOps 구조를 인식하면 강점을 식별하고 기존의 성공적인 프로그램 및 노력을 기반으로 잠재적인 위험을 인식하는 데 도움이 됩니다. 또한 계속해서 수요와 규모가 확장됨에 따라 DesignOps 구조의 발전을 계획할 수 있습니다.
이러한 구조를 참조할 때 다음 사항에 유의하십시오.
- 이 목록은 완전하지 않습니다. 이것은 일반적인 DesignOps 구조의 집합이지만 포함되지 않은 다른 모델은 디자인 팀을 성공적으로 지원할 수 있습니다. 또한, 두 개 이상의 모델의 하이브리드가 존재하는 것이 합리적이고 일반적입니다.
- 이러한 구조는 성숙도 모델이 아닙니다. 이러한 DesignOps 구조는 DesignOps 성숙도와 반드시 일치하지는 않습니다. 일부 팀의 경우 DesignOps의 전담 역할(즉, 단독형 구조)이 적절한 수준의 지원입니다. 따라서 높은 구조가 없다고 해서 DesignOps 관행이 성숙하지 않은 것은 아닙니다. 구조는 현재 및 가까운 미래의 조직 요구 사항을 기반으로 해야 합니다.
- 모든 케이스를 커버하는 최고의 구조는 없습니다. 여기에는 옳고 그름이 없습니다. 조직마다 상황과 필요에 따라 다른 구조를 사용합니다.
DesignOps: 5 Common Team Structures 를 학습하기 위해 번역하여 옮긴 글입니다. 오역이 있다면 언제든지 피드백 환영합니다.
'Design' 카테고리의 다른 글
| 에이전시 Frog가 말하는 DesignOps 101 (0) | 2022.04.29 |
|---|---|
| DesignOps란? 시작부터 끝까지 (0) | 2022.04.26 |
| content-to-chrome 비율 극대화 하기 (0) | 2022.01.21 |
| 데스크톱의 왼쪽 세로 네비게이션 (0) | 2022.01.20 |
| 네비게이션 디자인 트렌드 (0) | 2022.01.14 |