🌟 디테일의 간격 시리즈! [📝 와이어프레임의 중요성] (👀간단 요약) 📌 짧은 시간 내 기능 개발을 해야 하는 상황 ✓ 한정된 시간 앞에서 가장 어려웠던 건 사용자를 생각 할 수 있는 시간이 제한적이라는 것 ✓ 디자인 과정을 줄일 수 있는 방법에 대한 고민 ✓ 작은 단위의 개발을 하고 있기 때문에 와이어프레임의 필요성이 상대적으로 적다고 판단 ✓ 잘 갖춰진 디자인 시스템이 있기에 와이어프레임을 디자인 시안처럼 그려서 팀원들과 소통 📌 와이어프레임을 없애니 ✓ 그려진 화면이 완성 단계와 같아서 아이디어 발산이 자유롭지 못함 ✓ 니즈에 대한 검증보다 구현에 대한 검증이 먼저 : 이 기능 개발 가능한걸까? ✓ 자연스레 대화도 개발에 대한 이야기로 이어짐 : 팀원들의 충분한 생각을 들을 수 없음 📌 와이어프레임으로 '공유된' 이해 만들기 ✓ Invision 에서 제공하는 Freehand를 통해 아이디어를 발산할 수 있는 장 마련 ✓ 목표와 연관된 미션을 제시, 구성원별로 칸을 만들어 미션을 해결하는 방식 ✓ 하나의 같은 목표 이해, 같은 기능을 만들어나갈 수 있는 환경 마련 📌 와이어프레임을 모두가 이야기할 수 있는 장으로 만들기 ✓ 다음 프로젝트에서는 '정의'가 아니라 논의거리를 대충 던진다는 생각으로 러프한 와이어프레임 제작 ✓ 아이디어에 대한 뼈대를 1-2시간 안에 대강 그리고 정책을 적지 않음 ✓ 나머지는 팀원들이 와이어프레임 위에 자유롭게 의견을 적도록 함 ✓ 더 긴밀한 논의가 필요한 내용은 포스팅ㅅ과 같이 다른 형태로 기록, 회의 시간에 모두가 보며 논의 📌 와이어프레임으로부터 결과를 만들고, 맥락을 함께 보여주기 ✓ 위 방법을 계속 하다 보니 화면 위의 논의가 많아져 화면 자체에 대한 집중도가 낮아짐 ✓ 논의를 통해 정해진 내용은 휘발되지 안호록 노션에 있는 에픽문서에 따로 기록 ✓ 논의한 Freehand 링크를 함께 달아 다양한 이해관계자들이 의사결정의 맥락까지 함께 볼 수 있도록 함 ✓ 논의를 통해 완성된 디자인까지 함께 볼 수 있도록 구성 (의사결정 맥락 - 결과까지 한 눈에) (👋중요한 이유가 뭔가요?) 저도 최근에 스토리보드 없이 프로젝트를 진행하고 있어요. 스토리보드와 와이어프레임을 헷갈려 하는 분들이 있는데, 스토리보드는 와이어프레임과 기능명세가 결합된 형태로 보시면 될 것 같아요. 스토리보드 작성에 시간이 오래 걸리니, 와이어프레임과 기능정의만 가지고 빠르게 기능을 개발하는 것인데요. 문제는 '익숙함'이었어요. 스토리보드는 기능 개발의 기준이다. 라는 생각이 저부터도 깊게 깔려있었기 때문입니다. 그래서 이 글이 더없이 반가웠어요. 제가 업무 방식과 단계에서 고민하고 있는 과정과 맞닿아 있기에 더더욱. 저는 피그마 자체를 적극 활용하고 있어요. 피그마를 통해 1차로 와이어프레임을 스케치하고, 이에 대해 1차 리뷰를 진행해요. 기능에 대한 정의를 이미 확인한 상태기에 어떤 구성이 기능을 가장 잘 표현할 수 있는 방법인지 충분히 논의할 수 있는 시간이 됩니다. 저도 이 과정에서 가장 중요하게 생각한 건, 개입의 자유를 해치지 말자라는 것. 누군가 그럴듯하게 화면을 그려놓으면, 그 자체가 기준이 되기에 논의가 한 단계 앞서갈 수 밖에 없더라고요. 어느정도가 우리가 말하는 와이어프레임의 기준이냐! 는 아직도 진행형이지만, 이런 방법으로 일을 하는 분들에게는 더없이 중요한 자료가 될 것 같아 공유합니다.