🌟 디테일의 간격 시리즈! [💖신입 UX/UI기획자를 위한 10가지 실전TIP] (👀간단 요약) 📌UX/UI기획자의 실제 업무 - 조직에 따라 달라질 수 있음 1) 프로젝트 제안 2) 리서

🌟 디테일의 간격 시리즈! [💖신입 UX/UI기획자를 위한 10가지 실전TIP] (👀간단 요약) 📌UX/UI기획자의 실제 업무 - 조직에 따라 달라질 수 있음 1) 프로젝트 제안 2) 리서치 & 인터뷰 & 컨셉 설정 & 주요화면 UI 기획 (때에 따라서 인터뷰 생략) 3) IA(Information Architecture) 작성 4) UI 화면정의서 작성 5) 디자인 검수 (디자인을 우리 회사에서 할 경우) 6) 퍼블리싱 검수 (퍼블리싱을 우리 회사에서 할 경우) 7) 사용성 테스트 (프로젝트에서 요청 시) 📌가장 많이 사용하는 툴과 산출물 UI 기획자가 가장 많이 사용하는 툴은 파워포인트와 엑셀입니다. 파워포인트를 통해서 UI가이드 문서를 많이 작성하며, 해당 글에서는 UI 가이드 문서를 작성할 때의 주의점이나 TIP을 공유하고자 합니다. 📌히스토리와 버전 관리 UI 문서에서 표지 다음으로 시작하는 페이지는 문서 수정 히스토리를 작성한 페이지입니다. 문서를 배포한 버전, 수정 및 추가한 내용, 작성자, 수정 내용을 발의한 사람 등의 내용으로 구성됩니다. 보통은 색상으로 표시한 네모 박스 안에 수정된 내용과 버전, 날짜를 기입하여 수정된 내용을 찾기 쉽도록 합니다. 또한, 화면에서 수정된 내용도 동일한 색상으로 표시합니다. 사소하다고 느껴서 리비전 히스토리에 작성하지 않은 경우 디자이너나 개발자가 확인하지 못하고 이전 버전으로 계속 결과물을 공유할 수도 있습니다. 📌공통(Common)의 중요성 히스토리 다음으로 오는 페이지가 대개 ‘공통’ 항목이라고 정의되는 것들입니다. 다른 사람들이 나눠서 작업하더라도 공통적인 룰과 컴포넌트(요소)들로 작업할 수 있도록 하기 위함입니다. 여러 페이지에 들어갈 내용들을 공통으로 정의하면 모든 페이지에 내용을 수정하지 않아도 되는 이점이 있습니다. (하나의 문서를 여러명에서 작업 시 모든 페이지를 고려, 사전 공통 룰을 함께 정의하고 진행해야 함) 📌공통의 요소들 ✓GNB (Global Navigation Bar) / Footer / Menu (별도로 정의할 수도 있음) ✓처음 진입 시 (별도로 정의할 수도 있음)- 스플래쉬, 업데이트 정책, 튜토리얼(추가 시), 권한 설정 팝업(카메라, 전화번호 등) ✓데이터 로딩 시- 페이지 로딩, 이미지 또는 텍스트 로딩, 새로고침(폴다운 리프래시 시), 데이터 업데이트 시 ✓데이터가 없을 경우 case- 내용이 삭제되었거나, 데이터가 없는 경우 (ex. 마이페이지의 찜 화면/검색 결과 없음) ✓오류가 발생했을 때 case- 삭제된 페이지, 네트워크 오류, 접근권한이 없을 시, 시스템 점검 시 등 ✓팝업 유형 및 인터랙션 정의- 시스템 팝업(알럿팝업)/커스텀 팝업(레이어 팝업, 알림 팝업, 토스트 팝업 등) ✓입력란 인터랙션 정의- text 입력 전/입력 시/삭제 시/잘 못 입력 시 (Validation Check 포함) 등 ✓텍스트 표기법- 날짜, 시간, 금액, 전화번호, 나이 등 ✓페이지 네비게이션/더 보기 버튼 인터랙션 ✓선택 불가, 선택 가능, 선택된 상태 등에 대한 정의- 선택 불가 시 Dimmed 된 버튼 노출, 선택 가능한 상태인 경우 색상 변경 등 ✓댓글 영역 관련 정의(댓글이 없는 서비스의 경우 제공 안 함)- 인터랙션, 답글, 신고, 리스트 노출 개수, 글자 노출 수, 공유, 좋아요/싫어요, 댓글 없을 시, 그 외 관련 정책 등 ✓그 외 서비스에 따른 공통적인 정책 – 페이지 간 이동, 프로필 및 배지 노출 정책 등 📌빠뜨리기 쉬운 것들 제가 지금도 종종 빠트리는 case는 ‘아무것도 없을 때’의 케이스 정의입니다. 마이 페이지에서 내가 찜 한 상품이 없거나, 빅데이터를 통해 회원에게 콘텐츠를 추천해주는 case에서 쌓여 있는 데이터가 없을 경우, 검색 시 검색 결과가 없는 경우 등 사용자에게 보여줄 결괏값이 없을 때 어떻게 보여 줄지에 대한 정의입니다. 📌버튼이나 필터를 둘 때의 위계질서 예를 들면 단순한 리스트에서도 필터기능을 타이틀 옆에 둘 것인지, 아래에 둘 것인지 설정하게 됩니다. 같은 기능 버튼이라도, 어느 곳에 배치하냐에 따라 기능이 달라지기 때문에 공통된 룰로 배치하여 사용자로 하여금 혼란이 없도록 해야 합니다. 📌클릭영역과 입력영역의 최소/최댓값 화면 안에 입력 영역이나 타이틀, 버튼을 넣을 시 문서이기 때문에 해당 영역에 얼만큼의 텍스트가 최대로 입력될지, 클릭영역은 적당한지 예상하며 기획을 해야 합니다. 디자이너들이 화면을 그리면서 가이드를 주기도 하지만, 어느 정도 기획자가 고려하고 작업하지 않으면 조정 작업을 여러 번 거치게 되거나 디자이너들이 기능 버튼의 위치를 기획과 다르게 배치해야 하는 이슈가 생길 수 있습니다. 📌서비스 플로우 화면을 기획함에 있어서 누락되는 것은 없는지 점검할 수 있는 역할을 합니다. 이미 그려진 것들을 다시 배치하며 ‘이 버튼을 누르면 당연히 로그인 팝업을 띄워야지’하고 생각할 수 있는 것들도 ‘이 버튼을 누르면 내용을 입력해 달라는 알럿을 먼저 띄워야지’라고 생각할 수 있도록 만드는 항목입니다. 📌마무리 두가 해당 문서를 읽는 데 어려움이 없도록 ‘가이드’를 지키며 관련된 요소들을 설명하고 그려내야 합니다. 위에서 공통적으로 말하고 싶은 점은 "기획자의 말과 문서는 다른 사람을 이해시키기 위한 것"이라는 것입니다. (👋중요한 이유가 뭔가요?) 요즘은 PPT로 와이어프레임 등을 제작하지 않고, Figma / Overflow 등의 툴을 통합으로 쓰는 경우도 많이 보여요. 문서를 제작하는데 걸리는 시간을 논의 하는 시간에 더 투자하기 위한 방법으로 말이죠. 저 역시 지난 회사에서 2년 간 기획자로 일하며 PPT 보다 XD나 Overflow 등의 툴을 더 많이 활용했습니다. 빠르게 개발 리뷰를 하고 피드백을 반영할 수 있다는 장점도 있지만 기본 가이드가 누락 될 수 있다는 단점도 있는데요. 서비스 개발에 최적화된, 팀 만의 노하우를 잘 갖추고 있는 팀에 속해 있다면 크게 문제가 되지 않을 수 있지만, 반대의 경우라면 위에서 언급된 내용에 따라 문서를 제작하는 것을 추천합니다. 기획자 개인의 역량 강화를 위해서라도! 사이드 프로젝트 진행을 위해 오랜만에 PPT로 문서를 제작했는데 많이 낯설었어요. 놓치는 부분들이 많아 진다는 생각도. 장점의 관점에서만 생각하면 버전 관리부터 시작해 서비스의 디테일 한 과정 과정을 두루두루 살필 수 있습니다. 저는 개인적으로 '왜?' 에 대한 답이 그대로 녹여 있어야 한다고 생각해요. 우선 순위에 따라 무엇을 개발 할 지 결정 되지만, 실질적인 출발점은 기획자가 만드는 문서가 되는 경우가 많기 때문이에요. 그래서 가능한 정제된 근거자료를 많이 활용하는 편입니다. 그런 내용이 없다면 기획자의 주관적인 생각으로 만든 문서에 불과하기 때문이에요. 슬라이드의 많고 적음은 공유 전 다시 한 번 살펴보는 게 좋고, 그 전에는 이 문서가 디자이너, 개발자 등에게 충분히 이해 될 수 있고 수긍할 수 있는 내용인지에 초점을 맞춰 들여다 보는 것이 좋습니다 :)