[UI] 드리블(Dribbble) 리디자인 -3
디자인 사이트 드리블 리디자인하기 - 와이어프레임
들어가기 전에
-지난 글 보기-
왜 와이어프레이밍을..?
와이어프레임 단계는 사실 서비스 기획자가 있는 팀이라면 종종 서비스 기획자의 일로 치부되기도 한다. 하지만 와이어프레임은 사실상 UI의 구조, 구성, 위치를 설정하는 단계이기에 디자이너의 의견이 반영되거나 혹은 함께 진행하면 보다 좋은 결과물을 얻을 수 있을 것이라 확신한다.
그렇기에 꾸미기만 하는 디자이너가 아닌, 설계를 하고자 하는 디자이너들은 꼭 와이어프레임 단계를 경험해보고 꾸준히 고민해보아야 할 것이다.
이것의 목적
UI 스케치 단계에서 바로 프로토타이핑으로 넘어갈 수 있지만, 와이어프레임을 통해 기획을 탄탄히 하고싶은 마음이 컸다. 꾸밈(GUI의 영역)이 들어가기 전에, 스케치 단계에서 간과할 수 있는 실제 화면에서의 영역 문제나 버튼의 위치 등을 확인해보고 싶었다. 이 단계를 거치면 이후 디자인을 입히는 작업은 조금 더 수월해질 수 있다.
그럼에도 불구하고 사실 바로 스케치 상에서 나름 구체적인 화면 구성이 나왔다면 분명 스킵하고 넘어갈 수 있다. 오히려 그게 효율적일 수 있다. 이런 자세한 와이어프레이밍은 실제로 실무에서는 넘어가는 경우가 훨씬 많고, 혹은 기획서의 일부에 들어가있을 확률이 크다. 따라서 어디까지나 경험을 위한 경험이고 빠르고 효율적인 디자인 프로세스 상에서는 이상적인 과정이라고 생각하지 않는다.
지난 단계에 참고했던 글
https://uxplanet.org/basics-of-prototyping-1a4106e12c0e
말 그대로 와이어프레임
좌: 지난 번 스케치 우: 이번 와이어프레임 먼저 몇가지 규칙을 정했다.
1) 색은 고려하지 않기. 모두 Grayscale으로 작업했다.
2) 실제 화면에 담아 UI 설계를 하는 것인 만큼 폰트 사이즈나 카드 사이즈, 버튼 형태 등은 고려하며 제작하기.
3) 스케치를 바탕으로 플로우가 잘 이어지는 지 점검하며 빠진 부분 찾아 넣기.
스케치를 켜면 자꾸만 디자인(그래픽 영역)을 하려는 성향이 있어 색이나 그래픽를 고려하지 않았다. 대신에 화면에 들어갔을 때 크기나 영역 등은 미리 고민해보아야 한다고 생각해서 사이즈나 배치 등은 추후에 바뀔 수 있음을 감안하면서 어느정도 신경쓰기로 했다.
건너가고, 건너오고.
메인 페이지이번 와이어프레이밍은 손으로 그린 스케치를 바탕으로 UI 구성을 짜고 화면에 배치를 해보는 과정으로 진행되었다. 이선주님의 조언을 참고하여 선형 플로우를 만들어보았다. 선형 플로우에 대한 것은 아래 링크에 정리가 되어있다.
참고 : https://seanlion.github.io/ux/21
일직선 상에 화면을 두고나니 필요한 것이 보였다. 바로 화면이 넘어가고 또 돌아오는 여정이었다. 유저가 중간에 끊기지 않고 또 길을 잃지 않고 들어갔다가 나와야한다. 그러기 위한 버튼들이 적재 적소에 모두 배치가 되었는지 확인이 필요했다.
(편의상) 메인에서 좌측으로 넘어가는 것을 들어간다, 우측으로 넘어가는 것을 돌아온다로 정의하고 모든 화면에서 들어가고 나올 수 있는 버튼과 아이콘이 있는지 확인 했다. 들어가는 것은 핑크로, 돌아오는 것은 블루로 체크했다.
물론 첫화면에서 바로 검색(탐색)을 하면 필터 화면을 뛰어넘고 결과 화면으로 갈 수 있고, 하단 Tab bar가 있는 화면에서는 바로 첫화면으로 돌아갈 수도 있다. 일단 그러한 것들은 모두 배제하고, 넘어갈 수 있냐 없냐의 점검을 진행했다. 다행히 빠뜨리지 않고 잘 요소가 갖추어졌다.
문제가 발생!
문제가 발생! (초록색 화면들은 전 화면으로 돌아갈 수 없다)커뮤니티 카테고리에서 문제가 발생했다. 일단 커뮤니티에는 드리블 그룹(QnA, 정보 공유하는 커뮤니티 기능), 블로그, 잡보드 등의 3가지 하위 카테고리가 있는데, 커뮤니티 메인 화면에서 각 하위 카테고리로 진입한 후에 다시 메인으로 돌아가거나 다른 카테고리로 이동을 원하는 경우 돌아가지 못하거나 하단 Tab Bar의 아이콘을 눌러 진입해야했다. 이는 유저가 많은 혼란을 겪을 수 있는 포인트임이 분명했다. UI 스케치때 내가 놓힌 부분이다.
스타일쉐어 app이를 해결하기 위해 상단의 nav bar를 넣기로 했다. 개인적으로 애정하는(?) 스타일쉐어의 앱을 참고했다. 스타일쉐어의 하단 탭바 카테고리가 드리블 프로젝트와 유사했기 때문이다. 피드(홈 메인), 스토어, 업로드, 알림, 마이페이지로 이루어진 스타일 쉐어 앱은 피드와 스토어에서만 상단 navigation bar를 사용한다. 아무래도 피드 카테고리, 스토어 카테고리 내에도 다양한 컨텐츠가 있기 때문에 상단 nav bar에서 한번 더 하위 카테고리를 고정해두어 원하는 컨텐츠로 바로 이동하게끔 해둔 것 같았다.
gif 입니다. 깜빡거리기만 한다면 클릭해보세용상단 nav bar를 고정하면 아래 위로 고정된 영역이 있기 때문에 활용할 수 있는 영역이 줄어드는 아쉬움이 있으나 유저가 목적없이 탐색할 때 뿐만 아니라 목적을 가지고 탐색을 할 때 바로 이동할 수 있게하는 장점이 있다.
스타일 쉐어 스토어 홈에서 각 하단 카테고리별로 컨텐츠를 미리 보여주고 카드를 클릭하거나 모두 보기를 눌러 해당 카테고리로 이동이 가능하다. 이는 목적없이 탐색하는(window shopping) 사람들을 위한 것이다. '오늘 뭐 괜찮은거 있나?' 하며 쇼핑몰에서 시간을 때우는 사람들에게 컨텐츠를 보여주면서(혹은 추천해주면서) 흥미를 유발한다.
그런데 애초에 원하는 상품이 있는 경우도 있다. '나 오늘 가방 사야하는데...'라는 사람들은 이런 window shopping을 할 필요가 없다. 목적을 가지고 탐색을 하는 경우에는 해당 카테고리로 바로 이동할 수 있게 하는 게 중요하다. ' 자, 여기 가방은 여기에 모아뒀어. 여기서 골라볼래? ' 라고 이정표를 제시해 주어야 유저는 편하게 가방을 보는데에 집중할 수 있다.
GUI 는 나중에 다듬자..!!따라서 각 하위 카테고리로 바로 이동할 수 있는 상단 nav bar를 각 첫번째 페이지 (홈과 같은 기능)에 넣어두었다. 영역을 얼마나 차지 할 것인지, 어떤 형태로 할 것인지는 조금 더 고민이 필요해보인다.
이렇게 수정한 후 다시 플로우에서 양쪽으로 이동이 가능한지 체크했다. 필요한 부분에 돌아가기 버튼을 넣는 것으로 끊긴 길을 다시 뚫어주었다.
홈에서 각종 소식을 목적없이 서핑할 수 있도록 하고, 필요한 정보는 바로 터치하여 해당 컨텐츠로 들어갈 수 있고, 또 원하는 정보가 있으면 상단 nav bar를 통해 바로 이동하여 탐색이 가능해졌다. 하위 카테고리가 있다면 상단 nav bar는 어쩌면 선택이 아닌 필수처럼 느껴졌다.
(아무튼 해결..!)
모동숲 처럼..! (내 섬 아님 주의 ㅠ)마무리
노티 영역과 마이페이지 영역도 점검을 해보았다.
스케치에서 프로토타이핑으로 넘어가기 전 와이어프레임 단에서 한번 더 플로우에 대해 고민할 수 있는 좋은 경험이었다. 사실 숙련된 디자이너/기획자는 스케치 단에서 이미 이러한 것들이 모두 고려될 수 있기 때문에 이러한 단계가 오히려 시간 낭비일 수 있지만 처음 기획을 하거나 디자인설계를 하는 디자이너/기획자는 이러한 점검과정이 꽤 도움이 되고 오히려 이후 디자인 작업때 시간을 아껴줄 수 있을 듯하다. 바로 프로토타이핑을 하다가 이러한 문제가 발생됬을 때 수정을 할 생각을 하니 꽤나 아찔하다.
앞으로 스케치를 좀 더 꼼꼼히 하고 또 점검하는 과정을 통해 이러한 와이어프레임 단계를 뛰어 넘거나 빠르게 진행할 수 있을 것 같다. 이후 GUI를 입히는 작업에서 좀 더 시각적인 디자인에 집중할 수 있을 듯하다 ;)
참고 자료
https://seanlion.github.io/ux/21
+ 이후 작업에 도움이 될 참고 자료
https://brunch.co.kr/@dalgudot/98
*많은 관심과 오지랖과 피드백과 따끔한 조언은 큰 힘이 됩니다.
