Figma에서 개발자와 소통하는 방법
회사나 팀마다 비개발 직군과 개발 직군 간의 협업 방식은 천차만별입니다.
정해진 정답이 없기 때문에, 다른 팀들의 협업 방식을 참고해 우리 팀에 적용할 수 있는 부분을 도입하고 개선해 나가는 것이 중요하다고 생각해서
저희 팀의 협업 방식을 공유하고, 다른 메이커들의 방식과 피드백을 들을 수 있는 기회를 만들고자 이 글을 작성하게 되었습니다 😊
저희 팀은 피봇 후 팀 규모도 작아지고, 지금 디자이너가 없어서 제가 UI 디자인까지 하는 상황입니다.
그래서 PRD나 기획 문서는 최소화로 작성하고, 60~70%의 협업을 Figma에서 하고 있어요.
처음엔 정말 상세하게 Flow Chart도 그리고, UI 요소 하나하나 상세하게 개발 요청 사항을 작성했었는데
저희 개발자분들이 “글이 너무 많아 보기 힘들다.”고 의견을 말씀하시기도 했고,
"솔직히 이거 보고 100% 완벽하게 따라 해서 개발하는 것도 아니라서 비효율적이다."라는 피드백을 듣고 여러 방법을 시도해봤습니다.
그래서 지금은 BDD(Behavior Driven Development) 방법론을 저희 팀에 맞게 변형해 개발 요청 사항을 작성하고, Figma에서 진행 사항을 공유하고 있습니다.
왜 BDD 기반 협업이 필요할까?
(BDD에 대한 자세한 설명은 위 링크를 참고해주세요)
개발자와 비개발 직군 모두를 힘들 게 하는 질문이 하나 있죠.
이거 얼마나 개발됐어요? 언제 끝나요?
개발자 입장에선 진행률을 퍼센트(%)로 알려줄 수 없으니 난감하고,
프로젝트를 관리해야 하는 기획자, PMPO는 진행 사항을 알 수 없어 답답하죠.
그래서 애자일 방식으로 일하는 팀은 ‘데일리 스크럼’을 통해 진행 사항을 공유하는데,
‘실제로’ 얼마큼 진행되었는지 공유하는 건 쉽지 않은 일이죠 🥲
이런 문제를 완벽하진 않지만, 어느정도 해결할 수 있는 방법이 BDD 기반 협업이라고 생각합니다.
BDD는 이름처럼 ‘사용자의 행동’을 중심으로
목적을 이루기 위한 Story는 ‘As a… I want … so that …’의 틀을 갖춰 작성하고,
Task는 ‘Given - When - Then’ 양식에 맞춰 작성합니다.
이를 통해, 개발 요청 사항과 테스트할 내용을 동시에 공유할 수 있습니다.
그래서 소통 오류가 발생할 수 있는 모호한 Story만 보고 개발하는 것보다 기획 의도를 확실히 이해할 수 있고,
테스트 성공/실패 여부를 확인하면서 진행 사항을 파악할 수 있게 됩니다.
BDD를 변형해 정착한 지금 방식
BDD 관련 자료를 보고 “이거다!” 싶었어요.
그래서 개발 요청 사항을 읽었던 자료에 나온 양식 그대로 ‘Given - When - Then’ 양식에 맞춰 작성해서 개발자분들에게 공유했더니
“좋은데, 좀 투머치다!”라는 피드백을 들었습니다 😅
테스트할 내용을 기반으로 개발 요청 사항을 작성하니 이전 방식보다 이해하기 쉽고 좋은데,
양식을 그대로 따르기보다 필요한 내용만 더 간결하게 작성해달라는 요청이었습니다.
지금은 기존 BDD Task 작성 양식을 변형해
사용자가 우리 제품을 어떻게 사용하는지
어떤 상황에서/어떻게 사용하면 오류가 발생하는지
오류 발생할 때 어떻게 처리하는지
세 가지 내용을 담을 수 있는 컴포넌트를 만들어 활용하고 있어요.
맨 처음엔 가장 왼쪽 이미지에서 보이는 컴포넌트를 만들어 활용했어요.
체크박스의 간단함은 좋았지만, Task 상태를 true/false 2가지만 표시할 수 있어 아쉬웠습니다.
그래서 다양한 Task 상태를 표시하기 위해 가운데 이미지로 개선했고,
번호까지 있으면 좋겠다는 생각에 제일 오른쪽 컴포넌트도 만들어 활용하고 있습니다 👍
체크박스와 상태 표시는 'CheckBox' 'Status'라는 위젯을 활용해서 만들었는데요.
instance나 variant가 아니라 위젯을 활용한 이유는
위젯은 클릭만으로 상태 변경이 가능한데 인스턴스는 사이드 패널에서 바꿔야 하는 번거로움이 너무 귀찮다는 피드백을 들어서였습니다 🤣
여러분은 어떻게 협업하고 계신가요?
저희 팀의 방식에서 더 개선할 부분이나, 여러분의 협업 방식을 댓글로 남겨주시면 감사하겠습니다.
댓글
로그인 후 댓글을 남길 수 있습니다.
개발자는 좋겠네요. 디자이너 입장에서는 좀 번거로울 것 같은데... ㅎㅎㅎ
기존에 디스크립션이나 개발 요청 사항을 어떻게 적고 있는지에 따라 다를 것 같은데요! 저는 작성하는 내용이 이전보다 훨씬 줄어들어서 편해졌습니다 ㅎㅎ
음, 협업의 효율이 많이 해결되었나용?! 궁금하네요! 이것과 조금 다른 결이긴 한데, 저도 맨날 고민하는 일이 있어요. 화면 디자인이 되어도, 글로 설명되어야 하는 부분들이 있어서 디자인 아래에 디스크립션 또는 코멘트를 달아두거든요. 그런데 결국 놓치는 일이 발생하고, 명확성도 떨어지거든요. 이걸 어떻게 효율적으로 전달하고 반영시킬 수 있지가 항상 고민이에요.
저희 팀은 협업 효율이 많이 개선되었습니다! 기획 → 디자인 → 개발 → QA → 오류 수정 → 배포 이 사이클에서 특히 '개발 → QA → 오류 수정' 시간이 굉장히 짧아졌거든요. Task를 작성할 때, ‘Given - When - Then’ 양식까진 아니어도 어떤 상황에서 오류가 생기고 어떻게 처리해야 하는지 작성해둬서 그런지, 이전보다 QA할 때 기획 의도, 디자인 의도와 다르게 개발되는 경우가 많이 줄었습니다. 물론 이 방식이 완벽한 건 아니에요. 저희 팀이 BDD 방법론을 활용해 얻은 건 놓치는 부분을 0%로 만들었다는 게 아니라 (솔직히 불가능하죠 🥲) 디스크립션과 코멘트를 줄이기 위해 스케치, 와이어프레임 단계에서 더 많이 소통한 거라고 생각합니다. 여기에 Task 작성 방식의 변화까지 더해져서 효율이 개선되었다고 생각해요.
저도 이거 한번 시도해볼래요! ㅎㅎ 개인적으로 핸드오프 방식을 선호하지 않는 것 같기도 하고.... 이 고민을 저희 팀 보경님하고도 이야기 나눈적있어요 ㅠ 디스크립션 남기는게 맞을까요? 이 방법밖에 없을까요? 이렇게요. 근데 적극적으로 찾아보진 못했네요.. 감사합니다 :)
도움이 되셨으면 좋겠습니다 😊 제 방식보다 더 나은 방식을 찾으셨다면 꼭 공유해주세요!