개발자와 협업을 더 잘하고 싶은 디자이너를 위해
개바개를 잊지 마시길.
배경:
디자이너와 가장 가깝게 협업하는 팀원 중 한 명인 프론트 개발자분과 소통할 때 같은 문제를 보는 관점이 다른 점이 재밌게 느껴졌고, 어떻게 하면 서로 알아서 싱크를 맞춰서 커뮤니케이션 코스트를 줄일 수 있을까 고민해 봤어요.
가설:
개발자가 어떤 흐름으로 작업하시고 어떤 부분에서 진행의 병목이 생기는지 알면 협업의 효율성을 높일 수 있지 않을까?
그래서 특정 상황을 가정하고 문제 → 작업 착수 프로세스를 여쭤 보았습니다.
상황 가정:
이번 스프린트에서 “네트워크 오류를 알려주는 예외 화면을 추가”하는 Task를 할당받은 것을 가정하고, 디자이너와 개발자분이 해당 일감을 이해하고 실행하는 상황을 얘기해 봤어요. 먼저 디자이너인 제 생각의 흐름을 살펴보자면..
❇️ 디자이너:
1️⃣ “이 화면이 왜 필요하지?”
"아 이래서 필요하구나"
2️⃣ "유저가 이 화면을 마주하는 콘텍스트는 무엇이며, 유저가 느끼는 불만과 심각도는 어느 정도지?"
해당 Task의 중요도 판단
3️⃣ "이 상황을 마주한 유저는 어떤 기분이고, 어떤 행동을 하고 싶을까?"
해당 Task를 해결하는 수단과 방법 고안
4️⃣ "우리와 비슷한 도메인 서비스는 어떻게 하고 있지?"
사례 및 레퍼런스 리서치
5️⃣ 시안 제작 후 업무 이해관계자에게 피드백 요청
다음으로는, 개발자분에게 여쭤본 작업 흐름을 나열해봤어요.
⚙️ 프론트 개발자:
1️⃣ "내가 할 수 있는 일인지?"
프론트 단에서 해결할 수 있는 문제인지?
2️⃣ 이 일을 왜 해야 하는지?
이 일감의 목적과 예상 결과 판단
3️⃣ "다른 개발자는 어떻게 해결했지?"
관련되었거나 비슷한 사례 히스토리 확인
4️⃣ "기능을 구현하기 위해 어떤 협업을 요청해야 할지?"
이해관계자들과 논의 및 문서화
5️⃣ 업무 이해관계자에게 사이드 이펙트와 예상 이슈 공유
이런 문제가 있을 수 있지만, 구현하는데 문제없으니 최종 결정 요청
6️⃣ 상세 스펙 정의 및 구현
과정을 자세히 들여다보면 겹치는 부분도 있고, 많이 다른 부분도 있는 것 같아요.
개인적으로는 “이 화면이 왜 필요하지?”, “이 일을 왜 해야 하는지?”를 먼저 생각하는 부분이 비슷하다는 점에서, 이런 의문이 들지 않도록 목적이 확실한 기획이 중요하다고 느꼈습니다.
하지만 이 관점에서 더욱 중요하다고 느낀 것은, 디자인 핸드오프에 있어서도 "왜 UI를 이렇게 그렸지?"라는 의문이 생기지 않도록, 더 깊게 생각하고 작업해야겠다는 점이었어요.
디자이너라면, 어떤 일감을 받았을 때, 관성적으로 작업하는 경향이 누구나 한 번쯤은 있을 것 같아요.
저 역시 의식하지 않으면 관성적으로 화면을 그리는 모습을 마주하게 되는데, 보통 이렇게 그린 UI들이 다른 이해관계자에게 질문을 많이 받았던 것 같아요. 반성합니다..
회고:
최근 프론트분과 친하게 지내면서, 직무적으로도 많이 배우지만 협업이나 일하는 방식 관점에서 정말 많이 배우고 있는 것 같아요. 이번 글도 같은 맥락에서 어떻게 하면 내가 디자이너로서 더 잘할 수 있을까에 대한 고민이기도 합니다.
물론 함께 일하는 개발자분 성향에 따라 일하는 방식이 천지차이라서, 저의 사례가 큰 도움이 안 될 수 있지만, 중요한 건 이렇게 구조화해서 서로의 니즈를 이해하는 건 분명 도움이 된다고 생각해요.
다음 스프린트부터 이런 부분을 더욱 고려하면서 "의문이 들지 않는", "이 사람의 작업은 믿을 수 있는" 디자이너로 느껴질 수 있도록 잘 준비해 봐야겠네요!
