디자인 작업 사이즈 추정해보기

디자인 작업 사이즈 잘 추정하기

#Design #Process #ProjectManagement · 2023. 7. 15

디자인 작업 사이즈 잘 추정하기

#Design #Process #ProjectManagement · 2023. 7. 15

Notion 메모.

나도 잘 못함.. 모든 분야에 적용되는 것은 아니고 B2B Saas에만 해당될지도..? 디자이너 관점으로만 작성함. 원래는 이전 팀 안에서만 공유하려고 했는데.. 게을러서 작성을 하지 못함..

디자인 작업의 사이즈란 무엇일까?

문제를 해결하기 위해 필요한 디자인 작업의 단위와 난이도

어떤 문제를 해결해야하는가에 따라서 전반적인 기능, 메뉴 단위의 재설계가 될 수 있고, 복잡한 플로우를 설계해야 하거나, 화면 하나만 필요한 경우도 있음

복잡한 기능, 문제를 다루거나 진행해야 하는 프로젝트의 스펙이 크다면 당연히 난이도가 증가하고, 디자이너가 감당해야하는 작업의 사이즈도 커짐

반대로 단순한 화면 작업 또는 이미 많이 사용되는 기능 설계라면 상대적으로 난이도가 낮고 작업의 사이즈도 작아질 수 있음

작업의 사이즈는 해결해야할 문제의 난이도와 설계해야하는 기능의 복잡도, 화면의 케이스 개수등을 모두 고려해서 판단해야함

디자인 작업 사이즈를 판단하기 어려운 이유

디자인은 논리적인 설계도 중요하지만 기본적으로 작업자의 경험과 감에 많이 의존한다는 것을 부정할 수 없음

퍼널 중심의 단순한 플로우를 설계하고 표현하는 것은 상대적으로 메이커, 유저로서 많은 경험을 해보지만 B2B Saas 처럼 복잡한 도메인이나 특정 사용자만을 위한 플로우를 설계하고 표현하는 것은 애초에 경험이 적어서 매우 어려움

매 사이클마다 핵심 기능·플로우 이외에도 부수적인 기능들이 반드시 동반되는데 엔지니어링은 필요한 기술의 난이도와 구현 레벨의 의존성, 도메인 데이터등을 판단하여 작업 사이즈를 추정하기가 상대적으로 쉽지만, 디자인은 기술보다는 사용자 시나리오와 이전 제품 경험, 개인의 비주얼 감에 의존하는 경향이 있기 때문에 난이도와 사이즈를 추정하기 어려움

디자인 작업 사이즈를 판단하지 못하면 발생하는 문제

전제는 목적 조직에서 일한다고 가정하지만 보편적인 디자인 조직에 모두 해당될 것 같음

목적 조직은 보통 직군 단위로 1명씩 있기 때문에 작업 사이즈 추정이 좀 더 중요하게 작동함

기능 조직으로 일한다면 시니어 또는 리드 레벨의 디자이너가 판단하는 경우가 있지만. 지금까지 내가 경험해본 기능 조직도 보통 얼마나 걸릴 것 같은지 리드가 먼저 물어보는 경우가 많음

사이클내에 하나의 아이템에 얼마의 시간을 투자할 수 있을지 판단하려면 각 직군의 사이즈, 난이도 추정이 반드시 필요함

디자이너는 보통 프로세스 앞 단에 있기 때문에 예상치 못하게 디자인 작업이 길어지거나, 작업이 끝나지 않는 경우가 빈번하게 발생

엔지니어링도 비슷한 점이 있지만 디자인에서 좀 더 두드러지게 발생하는데 이유는 디자인 시안이 나온 상태에서 특정 스펙을 제외하는 결정은 상대적으로 쉽지만 디자인 과정중에는 스펙을 제외하는 수준의 즉각적인 의사결정을 하기 어려운 경우가 많음

디자이너가 디자인 사이즈를 추정하기 어려움과 겹쳐서 디자인은 보여지는 영역이고 의견을 이야기하기 쉬운 영역이기 때문에 많은 피드백을 받다보면 합리적인 의사결정이 안되는 경우가 빈번하게 발생

더 신경써서 설계해야 하는 플로우와 동작이 있는데 디자인 사이즈 측정을 못하면 선택과 집중이 잘 안되는 경우가 발생 (작은 범위에 매몰됨)

디자인 작업은 발산형 사고가 우선시되기 때문에 해결하고자 하는 문제에 대한 이해가 부족하거나, 사이즈 추정에 실패한다면 팀내에서 합의한 기능 스펙을 뛰어넘는 경우도 빈번하게 발생 → 보통 내가 겪는 문제…

디자인 작업 사이즈를 잘 판단할 수 있으려면

우선 팀은 디자인 탐색 프로세스에 대한 충분한 이해가 필요

문제를 찾아내고, 해결 방식을 찾아내는 것은 팀이 함께 하는 것이지만, 그게 올바른 방향일지 구현 이전에 다양한 방식으로 미리 확인할 수 있는 것은 디자이너가 주도적인 역할을 하는 지점임

따라서 문제를 정의하고 해결 방향이 합의되었다면, 팀은 사이클안에서 디자이너가 충분히 ‘디자인 탐색’을 할 수 있는 시간을 보장해야함

제품 설계 과정에서 디자인 탐색이란 핀터레스트, 드리블을 돌아다니면서 레퍼런스 수집이 아님

현재 우리의 제품 기조와 유저 시나리오 안에서 충분히 실행 가능한 해결책인지, 디자인 시스템의 패턴과 맞는지, 유저 관점에서 좀 더 나은 해결책은 없을지 말 그대로 디자인 방향성 탐색을 진행하는 과정

디자이너는 조금 더 복합적인 노력이 필요

본인이 만들고 있는 제품에 대한 이해가 필요

사용자의 니즈나 어떤 가치를 줘야 하는가 같은 기초적인 이해가 아님

현재 우리 제품의 기능들은 어떻게 동작하고 있으며, 어떤 도메인과 도메인 사이에 의존성이 있고, 내가 다루고 있는 데이터는 어디서 어떻게 오는지, 어디를 향해서 가는 것인지, 우리가 만들고 있는 패턴을 다른 제품 팀(내부)에서는 어떻게 풀었는지 등 실질적인 제품에 대한 지식이 매우 많이 필요함

본인의 제품에 대한 이해가 있어야 본인이 설계해야 하는 기능, 화면을 어떤 구조로 만들어야겠다는 단서를 찾을 수 있으며 구체적인 난이도 예측이 가능함 (이해가 부족하다면 당연히 단서를 찾거나 탐색을 진행하는데 오래걸림)

의외로 본인이 만들었는데 테스트 과정에서만 사용하고 실제로 안써보는 경우가 많음..

해결해야 하는 문제에 대한 충분한 이해 또는 공감

제품 팀 안에서 디자인의 과정은 ‘문제를 올바르게 정의하고 표현에 기반한 근본적인 해결책을 찾아내는 과정’임

문제에 대한 이해나 사용자의 불편에 대한 공감이 없다면, 근본적인 해결책이나 팀 안에서 공감이 될 해결책을 찾는 것은 어려워지며 더 많은 시간을 디자이너가 사용해야함. 결국 난이도와 사이즈 예측을 실패하게 만듬

다른 제품에서는 어떻게 해결하고 있는지 지속적인 리서치가 필요

바퀴를 재발명할 필요는 절대 없음.. 보편적인 기능이거나 비슷한 도메인을 다루는 제품이라면 참고할 수 있는 요소들이 있음

시각적인 것을 참고하는 것보다 구조, 기능, 동작에 대한 것을 참고하는게 좀 더 효과적임. 난이도를 올리는 주요한 요소가 기본 구조 설계나 동작이 어떻게 되어야 자연스러운지 감을 잡을 수 없기 때문

참고할 수 있는 자료들이 많다면 당연히 난이도가 낮아지고, 참고 자료와 대조하여 작업 사이즈를 훨씬 구체적으로 판단할 수 있음

내가 잘 하려고 노력하는 방법들 → 정답도 아니고 나도 잘 못함..

디자인 작업 일정을 약간 보수적으로 잡으려고 노력함

사이클 일정에 영향을 줄 수 있는 정도는 아니지만 평소 내 작업 과정을 기준으로 판단하여 공유함

늘 정해진 사이클을 운영하는 우리 팀의 경우 효과적인 디자인 탐색을 위해서는 디자이너가 시간에 대한 압박을 적게 받는것도 중요함

적절한 시점에 공유

완성된 시안을 적절한 시점에 공유해라 같은 맥락이 전혀 아님

팀에 현재 진행 상태나, 어려운 점 또는 이해가 더 필요한 점 같은 것들을 자주 공유할 수 있도록 노력함. 확정안이 아니라 탐색중인 과정임을 분명히 밝히며 필요에 따라서는 피그마 링크가 아니라 키스크린 이미지 또는 텍스트만 공유함

현재 어려운 점, 예상치 못한 문제를 적시에 공유해야 팀 레벨에서 문제 해결 방향에 대한 전략을 수정할 수 있는 기회가 있으며 디자인 탐색 방향을 수정하거나 작업의 사이즈를 재조정할 수 있음

이슈트레커 활용

현재 무엇에 집중하고 있고, 이후에 어떤 작업이 예정되어있는지 스스로 예측할 수 있어야하며, 팀도 내가 현재 어떤것을 하고 있는지, 어디서 시간이 오래 걸리는지 알아야 대처를 할 수 있음

디자인 내용을 플로우 단위 또는 화면 단위로 티켓으로 만듬

플로우에서 어떤 화면이 필요한지, 누락되었는지, 챙겨지면 좋을지 미리 만들어둠. 시안을 그려보기 전에 대략적인 화면들을 미리 상상하고, 작업 사이즈를 추정해볼 수 있음

또한 제품팀의 다른 멤버들이 보았을때도 디자인 작업 사이즈가 어느정도인지 파악할 수 있음

구두, 슬랙으로 논의 했던 과정에서 도출된 디자인 고민이 필요한 이슈들도 모두 티켓으로 만듬

예상치 못하게 작업 난이도, 사이즈를 키우는게 바로 커뮤니케이션 이후 휘발된 이슈

작은 이슈들은 막바지 단계에서 충분히 대응할 수 있지만 치명적인 이슈들은 디자인, 구현을 줄줄이 수정해야하는 불상사를 만듬

제품을 설계할 때 신경써야 하는 플로우나 동작에 대한 기준을 만듬

새로운 동작 시도

제품 안에 없는 UX 컨벤션은 매우 치밀하게 설계해야함

되도록이면 기존 패턴을 따르는게 좋지만 만약 새로 만들기로 했다면, 정말 제대로 해야함 → 다른 디자이너도 따라서 적용해볼 수 있을 정도

신규 메뉴 & 기능 또는 리뉴얼

기본적으로 플로우가 길거나 복잡한 경우가 많으며 챙겨야할 스펙의 절대적인 양이 많음. 따라서 디자인 탐색, 사이즈 추정에 대한 싱크가 챕터, 제품 팀 안에서 계속 필요함

전체 플로우를 모두 만든 다음 핸드오프할 필요는 없음, 일반적으로 생성 화면이 가장 먼저 필요하며 이후 조회(목록 포함)와 수정, 검색·정렬·필터, 특수한 케이스(삭제, 로딩, 권한과 연관된 케이스 등) 순으로 필요함

벌크 액션 설계

단일 데이터 구조로된 목록이라면 괜찮지만, 복잡한 데이터 구조나 그룹핑을 갖고 있다면 설계하기 매우 어렵거나 불가능함

벌크 액션을 스펙에 포함하고 싶다면 디자인하기 전에 현재 만들고 있는 화면, 기능의 데이터 구조가 동일한지부터 고려해야 함

내가 재미를 느낄 수 있는 요소를 포함시키려고 노력함

새로운 UX 패턴 적용, 비주얼적인 시도라던지. 디자이너들이 신경쓰는 이런 요소가 사용자들에게 사려깊게 느껴지는 경험으로 작용하며 디자인 작업의 사이즈를 추정할 때 이런 흥미 요소에 신경쓸 수 있는 여력을 만들어놔야 긴 호흡으로 작업이 진행되어도 심적으로 지치지 않을 수 있음