제품 디자인 문서를 통한 문서화 및 팀 커뮤니케이션 향상

게시 됨: 2022-03-10

요약 요약 ↬ 설계 제안서에 승인을 받기 위해 고심한 적이 있습니까? 디자인 프로세스를 공식화해야 한다고 생각하십니까? 원격으로 디자이너로 일할 때 COVID19 시대가 도전이 되고 있습니까? 그런 다음 이 기사에서 디자인 프로세스를 문서화하는 방법론을 알아보기 위해 계속 읽으십시오.

회사나 신생 기업에서 제품 디자이너로 일하는 일반적인 프로세스는 익숙할 것입니다. 즉, 디자인 솔루션을 제공하기 위해 새로운 제품이 개발되고 있습니다. 그런 다음 몇 가지 디자인 제안을 작업하고 1-3명 앞에서 프레젠테이션하여 피드백을 수집합니다.

이 프로세스가 잘 작동하는 경우도 있지만 그렇지 않은 경우도 있습니다. 예를 들어, 어떤 사람들은 자신의 작업을 완료하기 위해 주의를 기울이느라 바쁘고 디자인 제안에 대해 명확하고 간결한 피드백을 제공하는 데 충분한 시간을 할애하지 않습니다.

또한 프로세스가 양호하더라도 특히 COVID19로 인해 원격으로 작업해야 하는 현재와 같이 일반적으로 의사결정을 기록하고, 반복을 추적하고, 디자인 프로세스를 추적하여 프로세스를 공식화하고 싶을 수도 있습니다.

프로세스를 문서화하면 많은 이점이 있습니다. 예를 들어, 작업을 더 잘 보이게 하고, 더 많은 사람들로부터 피드백을 얻을 수 있는 기회를 만들고, 전반적인 커뮤니케이션을 개선하고, 모든 컨텍스트와 고려 사항을 고려하여 기능이 어떻게 설계되었는지에 대한 명확한 그림을 제공합니다.

영웅 디자이너의 몰락

2018년 즈음 저는 라틴 아메리카에서 운영되는 회사에서 마드리드에서 원격 제품 디자이너로 일하고 있었습니다. 이 프로세스에는 멕시코와 브라질 상파울루의 다른 팀이 참여했습니다.

이 회사에서 일하기 전에 뉴스 미디어, 디자인 스튜디오, 소셜 네트워크, 모바일 OS, 전자 식료품 스타트업 창업 등 다양한 분야에서 크고 작은 환경에서 다양한 경력을 쌓았습니다. , 심지어 다른 소규모 신생 기업과 프리랜서 공연을 하기도 했습니다.

그 몇 년 동안 나는 같은 접근 방식을 따랐고, 같은 방에 몇 사람을 앉히고, 솔루션을 발표하고, 화면을 제공하고, 흐름을 제공하고, 피드백을 받고, 다시 발표했습니다. 몇 번 반복하면 작업이 개발 단계에 도달할 준비가 됩니다.

그러나 이 동일한 접근 방식이 작동을 멈췄습니다. 팀에 합류한 지 얼마 되지 않아 영상 통화에서 내 디자인을 홍보하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 많은 제안서를 작성했지만 이해 관계자와 팀원의 최종 승인에 도달하지 못했습니다. 나는 혼란스러워 스스로에게 계속 물었다. 무슨 일이 일어난 거지? 내가 가능한 최고의 솔루션을 설계하지 않았습니까? 나는 좋은 품질의 작품을 제공하지 않았습니까? 그 질문들 하나하나가 나 자신에 대한 자신감을 잃게 만들고 있었다. 문제는 내 프로세스를 이 환경에 적응시켜야 한다는 것이었습니다.

점프 후 더! 아래에서 계속 읽기 ↓

내 프로세스가 작동하지 않는다는 것을 깨닫자마자 원격으로 디자이너로 일하는 방법, 갈매기 효과(누군가 당신의 작업에 들어오면 가혹하게 비판하고 날아가는)에 대한 많은 기사를 읽기 시작했습니다. 다른 회사들은 원격 협업에 접근하고 있었고, 이를 문서화하여 프로세스를 공식화하는 방법을 알고 있었습니다. 이 모든 자료를 읽은 후 개발자들이 이와 같은 문제에 어떻게 직면했는지 궁금했습니다. 거의 비동기식으로 원격 환경에서 어떻게 협업합니까? 그들은 어떻게 최종 합의에 도달합니까? 사실 개발자 커뮤니티에는 이미 잘 작동하는 프로세스가 있다는 것을 알게 되었습니다. 바로 pull 요청이라고 합니다.

끌어오기 요청을 사용하면 변경 사항을 문서화하여 더 큰 코드베이스에 변경 사항을 도입하고 다른 사람의 피드백으로 결정을 확인할 수 있습니다. 이러한 방식으로 도입한 변경 사항은 코드가 이미 있는 모든 표준 및 연결과 완벽하게 혼합됩니다. 이것은 내가 달성해야 하는 것과 정확히 일치하지만 물론 디자인-패션 접근 방식에서 이루어집니다. 제품 디자인 문서를 소개하겠습니다.

제품 디자인 문서

PDD(제품 설계 문서) 는 해결하려는 문제, 컨텍스트 및 최종 솔루션을 반복 또는 단계 기반 접근 방식으로 변환하는 문서입니다.

즉 , 전체 설계 프로세스 를 회사의 모든 사람과 공유할 수 있는 단일 문서로 문서화할 수 있으며 이는 제품 결정을 위한 지식 기반으로 남게 됩니다. 멋진 것 같죠? 자세한 내용을 살펴보겠습니다.

전반적인 개념

PDD는 Metadata, Context, Stages 및 Feedback 의 4가지 주요 개념으로 설명할 수 있습니다.

메타데이터 는 제목, 날짜, 상태 등과 같은 문서에 대한 유용한 정보일 뿐입니다.
컨텍스트 는 다른 사람들이 읽어야 하는 것입니다. 디자인 제안을 이해하려면 설명, 문제, 요약 또는 달성해야 할 목표와 같이 생각해야 합니다.
단계 는 일반적으로 보다 광범위한 솔루션에 초점을 맞추고 각 단계에서 보다 구체적인 세부 사항에 초점을 맞추기 시작하는 디자인의 다양한 반복입니다. 각 단계는 이전 단계를 기반으로 하며 받은 피드백을 다룹니다. 이것은 해결된 문제가 다시 나타나지 않는 최종 지점에 도달하는 구조화된 방법입니다.
피드백 은 다른 사람들로부터 수집한 모든 의견, 의견, 요청 및 권장 사항을 나타냅니다. 이해 관계자 또는 팀 구성원으로부터 피드백을 수집할 수 있습니다.

이 네 가지 개념을 사용하면 필요에 따라 PDD를 다양하게 변형할 수 있습니다. 모든 회사/프로젝트는 다르며 저에게 효과가 있었던 것이 동일한 방식으로 작동하지 않아도 됩니다. 그러나 PDD에서 이 4가지 주요 개념을 다룬다면 거의 모든 상황에서 작동할 것입니다.

예제 구조

주요 개념을 이해한 후, 제가 그 회사에 있을 때 사용했던 구조를 여러분과 공유할 것입니다. 다음 섹션이 있습니다.

제목 은 간결하고 명확해야 하며 이미 가지고 있는 다른 PDD 제목과 쉽게 구별할 수 있어야 합니다.
상태 는 현재 문서가 어느 단계에 있는지 나타냅니다.

초안
여전히 컨텍스트 정의 작업 중입니다. 피드백을 받을 준비가 되지 않았습니다.
S30, S60, S90
솔루션의 다양한 단계(30%, 60%, 90%)(단계에 대한 자세한 내용은 나중에 참조).
완벽한
모든 피드백이 처리되었으며 누락된 점이 없습니다. PDD가 완료되었습니다.

초록 은 설계해야 하는 문제에 대한 설명이며 일반적으로 다른 유용한 관련 판독값에 연결됩니다.
목표 는 솔루션이 집중해야 하는 핵심 사항이며, 올바른 방향으로 가고 있는지 확인하기 위해 지속적으로 검토해야 하는 체크리스트입니다.
S30 (또는 Stage 30% )은 세부 사항 대신 더 광범위한 솔루션에 초점을 맞춘 추상 및 목표를 기반으로 하는 첫 번째 제안으로, 저충실도 와이어프레임 또는 유사한 기술을 제공함으로써 가능합니다. 이것은 제안된 솔루션이 완전히 다른 접근 방식을 취할 수 있고 주요 피드백이 발생할 것으로 예상되는 단계입니다.
S60 (또는 Stage 60% )은 완성도가 60%인 솔루션이며 S30의 피드백을 적용합니다. S90보다 세부 정보가 적지만 솔루션의 의도를 명확하게 나타냅니다. 더 많은 사례와 일부 흐름 정의가 포함된 충실도가 높은 와이어프레임을 제공합니다. 놓친 사례와 예상치 못한 작은 시나리오에 중점을 둔 일종의 피드백을 받을 수 있습니다.
S90 (또는 Stage 90% )은 90%의 완성도에서 솔루션을 가지고 S60의 피드백을 적용하는 단계입니다. 이 단계는 다양한 시나리오, 코너 케이스, 시각 디자인, 프로토타입을 포함하여 디자인의 가장 미세한 세부 사항에 초점을 맞춥니다. 약간의 피드백이 있을 것으로 예상됩니다.

동일한 순서와 단계 명명 규칙을 따라야 합니까? 글쎄, 당신은하지 않습니다. S30, S60 및 S90에서 단계 이름을 탐색, 제안, 솔루션으로 바꿀 수 있습니다.

가장 세련된 작업(S90, Solution)이 문서의 맨 위에 표시되고 읽기 흐름이 최종 단계에서 초기 단계(S30, 탐색)로 이동하도록 순서를 변경할 수도 있습니다.

템플릿

가장 일반적인 쓰기 플랫폼에 대해 제공된 템플릿 중 하나로 빠르게 시작하십시오. 기억하십시오: 섹션의 명명 규칙은 완전히 사용자 정의할 수 있습니다. Abstract 가 마음에 들지 않으면 Brief , About 또는 필요에 맞는 것을 사용하십시오. 유지해야 할 주요 개념은 각 단계에 초점을 맞추기 위해 서로 다른 반복을 만드는 것입니다. S30은 탐색으로, S60은 제안으로, S90은 솔루션으로 이름을 바꿀 수 있습니다.

종이
개념
구글 문서
실제 사례

PDD 사용의 주요 이점

모든 결정은 문서화됩니다.
즉, 회사/프로젝트를 떠날 때(그리고 조만간 일어날 것입니다), 주변에서 생성된 모든 지식이 회사에 영원히 남게 되므로 다른 사람들이 보고 떠난 곳에서 반복할 수 있습니다.
의사 소통을 향상시킵니다.
PDD에서 팀의 다른 사람들이 피드백을 제공하도록 하면 모든 사람이 같은 페이지를 유지하고 내린 결정을 인식하는 데 도움이 됩니다.
이해관계자의 끝없는 변화를 제한합니다.
모든 단계는 더 넓은 솔루션에서 좁은 솔루션에 이르기까지 문제의 다른 각도에 초점을 맞춥니다. 이것은 사람들이 한 번에 하나의 문제에 집중할 수 있도록 하여 마무리 단계에서 도움을 줍니다.
제품은 공동으로 제작됩니다.
이해 관계자가 특정 솔루션을 정의하는 대신 엔지니어링, 설계 및 기타 팀이 솔루션에 참여하여 솔루션의 일부가 되도록 합니다.

최종 메모

이 원격 회사에 대한 이야기를 끝내고 나는 그곳에서 몇 달 더 일하게 되었고 최소한 5개의 다른 프로젝트에서 제품 디자인 문서를 구현할 수 있었습니다. 불만이 많이 줄어들었고 디자인 제안에 대한 합의에 도달하여 제품이 계속 발전했습니다. 그 이후로 회사는 많이 성장했고 내가 일한 시간 중 일부는 여전히 사용 중입니다.

추신: 2019년에 이 기사를 쓰기 시작했고, 2021년에 Abstract가 디자인 프로세스를 문서화하기 위한 제품을 만들고 있다는 것을 보고 다시 원래대로 돌아가 마무리하기로 결정했습니다. 여전히 관련성이 높은 주제인 것 같습니다.

서지

Hannah Hearth의 원격 팀에서 설계 연습을 실행하는 방법
갈매기 효과를 피하십시오: Lauren Moon의 피드백을 위한 30/60/90 프레임워크
디자인 문서는 어떻게 디자인하나요? 존 사이토
Brendan Fagan의 디자인 문서의 힘
Matt Colyer의 노트북 소개