UX가 궁금한 개발자에게 보내는 편지
방법론과 포스트잇, 화면 설계서에 대해서
주말에 프론트엔드 개발을 하는 친구를 만났습니다.
친구 : 내가 작은 곳에 있다 보니까 역할이 딱 나뉜 게 없고 이것저것 다 하게 된다. 그리고 뭐? U.. UI? UX? 이걸 알아 두어야 할 것 같은데 알려줄 사람이 없어. 디자인이랍시고 스케치해놓은 거 갖고 오는데 이게 맞나 싶고…. UI 결과물이 어떻게 나와야 하는 건지, 어떻게 하는 건지 궁금하다. XD 좋아 보이던데 그걸로 하면 되는 거냐? 내가 UI 직접 해보고 싶거든. Lean? 그건 또 뭐냐? 책 읽어보니까 뻔한 소리밖에 없고 포스트잇을 막 덕지덕지 붙이는데 그건 도대체 무슨….
나 : 이거 얘기하려면 적어도 3시간 짜린데… 일단 밥부터 먹고 내일 참고할만한 링크 포함해서 카톡으로 보낼게. 그리고 다시 얘기하자.
친구 : ㅇㅋ
이 친구가 프론트엔드 개발을 하고 있는 건 알고 있었지만 어떤 회사에서 어떤 업무를 하고 있는지는 정확히 알지 못했습니다. 말해줬는데 제가 대충 들었을 가능성이 높지만요. 아무튼 얘기를 더 나누다 보니 UX 프로세스와 산출물 형태에 대해 궁금해했습니다. 자신이 맡은 개발 외의 영역. 그중에서도 UI에 대해서 말이죠.
지금부터는 UX와 UI를 처음 손대려는 저의 개발자 친구에게 보내는 답장입니다. 카톡으로 한마디씩 얘기하다 보면 언제 끝날지 몰라서… 그냥 한 번에 쭉 써놓고 복붙 할 생각으로 적어 보았습니다만, 혹시, 비슷한 상황이거나 이제 막 UI를 배워나가는 분께 조금의 도움이라도 될까 싶어 Ctrl+V 합니다.
※ 본 글은 UX 방법론과 포스트잇의 역할, 화면 설계서 작성법에 대한 내용을 간략히 담고 있습니다.
출처 : 이말년 서유기린이 건 린스 건 중요한 건 뭐냐면
일단 UX 방법론에 대한 개념부터 짚고 넘어가자. 지난번에 너가 말했던 린(Lean)이라는 건 UX 방법론 중 하나야. Lean, Agile, Sprint와 같은 방법들은 디자인 > 빌드 > 테스트를 빠르게 진행하면서 검증과 개선을 반복하는 특징이 있지. 반면 UCD (User centered design), 전통적인 Waterfall 방식은 리서치 > 분석 > 문제 정의 > 컨셉 및 전략 > 디자인 > 빌드 > 테스트와 같이 하나의 단계를 마치면서 검증하고 다음으로 넘어가는 선형적인 진행 방법이라고 할 수 있지. 워터폴... 마치 폭포가 위에서부터 떨어지듯이 모두가 지옥으로 떨어ㅈ
Lean 보다 앞서 알려진 Agile과 UCD에 대한 차이는 이 글을 참고하길.
Agile과 UCD (User Centered Design)
그리고, 작년 애자일 콘퍼런스에서는 애자일 프로세스와 조직을 적용한 기업의 이야기를 들어볼 수 있었어.
회사 대표님이 2013년에 Lean UX 도서를 읽고 쓴 독후감이 있어. 작성한 날로부터 시일이 많이 흘렀긴 하지만 린 UX가 무엇인지 이해하는데 도움이 될 것 같다.
그런데 이런 방법론을 꼭 알아야 할까? 그게 중요할까?라는 질문이 생길 수도 있어. 나는 새로운 프로젝트를 시작할 때 항상 이런 생각을 해. 내가 도출하는 포인트 하나, 제안하는 콘셉트 하나, 연결하는 플로우 하나. 이 모든 건 사용자를 위한 길이어야 한다는 것.
출처 : 이말년씨리즈자. 아무튼, 사용자가 미처 깨닫지 못했던 즐거움, 편리함, 유용함 등을 주기 위해, 그들의 마음에 닿기 위해 어떤 포인트로 콘셉트를 잡고 플로우를 설계해야 할까? 어떻게 일을 진행해야 그 길을 발견할 수 있을까? 여기서 출발하면 대략의 프로세스가 머릿속에서 그려지거든. 이게 되려면 미리 알고 있어야 해. 생각한 프로세스에서 어떤 기술과 방법이 필요한지. 누구의 도움을 받고 무슨 일을 해야 하는지 등등…. 결국, 방법론은 응용해서 써먹기 위한 기본 스킬 같은 거지. 간혹, 일이 잘 안된다고 방법론을 탓하는 사람이 있는데 그건 방법론이 문제가 아니라 그 방법론을 선택한 사람의 문제이고, 운영이 잘 안된 탓이 대부분이야.
어떤 프로세스를 탈 것이냐는 인력, 비용, 협업 환경 등도 고려해야겠지만 무엇을 하는 건지에 따라서도 접근을 달리 해 볼 수 있지. 우리가 인벤에서 흑마법사 공략을 보긴 해도 공략하는 대상에 따라 스킬 트리와 특성은 달라지듯이 말이야. 아래 글을 참고해 봐.
보다 빨리, 자주, 적은 비용으로 실패하기
조금 더 최근에 작성된 이 글도 정리가 잘 되어 있어.
Waterfall vs Agile - Nick Babich
붙~떼 붙떼 포스트잇
UX 하는 사람들의 시작과 끝에는 항상 포스트잇이 있지. 그런데 이것도 한물갔어. 아니다, 여전히 유용한 도구이긴 해. 아이디어를 발산하고 생각을 정리하기 위한 도구일 뿐이야. 단어와 문장, 혹은 간략히 그린 화면들을 오브젝트화 시키는 거지. 이렇게 하면 기억이 흐려지고 순서가 꼬이지 않도록 일시적으로 보존할 수 있고 아이디어나 개념들을 구조화시켜서 커뮤니케이션하기 쉬워지지. 사용자 조사 후 포스트잇을 사용하는 방법은 다음 글을 참고하길.
사용자 데이터, 포스트잇!으로 정리하기
그리고 포스트잇이 수단이 아닌 목적이 되어서는 안 된다는 경종을 울리는 이 글도 재밌어.
그 망할 놈의 포스트잇을 버려야 중급이 된다
포스트잇을 쓰는 것도 제약이 있긴 해. 많은 양의 데이터를 한 번에 붙여서 볼 수 있는 보드와 공간이 있어야 효과적이거든. 경우에 따라서는 여러 개의 보드를 레이어처럼 겹쳐서 보고 싶을 때도 있고 말이야. 요새는 이런 니즈를 반영한 협업 툴도 나오고 있으니 써보면 좋을 것 같아. 처음부터 디지털로 작업하면 생성과 편집, 이후 모델링 작업으로 연결까지 편리한 부분이 있겠지.
출처 : miroResearch와 Define 단계에서 활용하는 추천 협업 툴
Miro : https://miro.com
Figma : https://www.figma.com
입자이너 말고 디자이너
자, 다음은 네가 가장 궁금해했던 내용. 개발 전 단계의 UI 산출물이 어떻게 나오는가에 대해서야.
기획, 디자인, 개발 이렇게 세 가지 역할로 보았을 때 UI 기획/디자이너들은 어쨌든 간에 결국 화면과 시나리오를 만들어내지. 뭐, 프로젝트 상황에 따라 사용자 조사 후 전략을 세우고 끝내거나 가이드라인 정도만 정의할 수는 있어. 하지만 양산을 전제로 했을 때는 개발 조직과 그래픽 디자이너에게 전달하기 위한 산출물이 따로 있지. 부르는 명칭이 조금씩 다른데 우리는 보통 ‘화면 설계서’, ‘UI 설계서’, ‘규격서’, ‘와이어프레임’ 등등으로 불러. 클라이언트나 각 관계자들끼리 협의만 되었다면 뭐라고 부르는지는 크게 중요하지 않아. 이름에 대한 것은 이 글을 참고해 보면 좋을 듯.
아무튼 화면 설계서는 서비스의 규모와 구조, 화면을 구성하는 기능과 요소, 각 화면의 관계와 사용 흐름을 담고 있어. 이 문서를 보고 서비스의 골격인 IA, 각 기능들의 관계와 작동 방식, 상황별 특이점이나 형상을 이해할 수 있어야 해. (이 외에 컴포넌트의 포지션, 컬러, 크기, 타입 스타일 등의 정의와 리소스 제작은 그래픽 디자이너의 전문 영역이라 할 수 있지.)
지금까지 현업에서는 이 문서를 주로 Mac의 키노트나 MS Office의 파워포인트로 작성해 왔어. 그런데 요즘은 스케치나 어도비 XD와 같은 프로토타이핑 툴로 작성하는 경우도 많아졌지. 페이지 단위의 키노트와 PPT, 스페이스 개념의 스케치와 XD는 서로 다른 스타일로 인해 장단점이 있기는 해. 단순히 화면(그림)만 스케치나 XD로 빠르게 그려내고, 그 외의 작업은 키노트나 PPT로 이어서 하는 경우도 있어. 이것도 그래픽 디자이너와 개발자 혹은 사업부와 함께 어떻게 일을 진행하냐에 따라 다른 거라, 프로젝트의 각 역할자들이 협의해서 정하면 되는 부분이야.
지금부터 얘기하는 건 키노트나 파워포인트를 이용한 전통적인(?) 화면 설계서 작성법이야. 문장에도 주어, 서술어, 목적어 등등의 문장 성분이 있듯이 설계서에도 대체로 포함되는 주요 성분들이 있어.
<화면 설계서의 7가지 성분>
표지
히스토리
목차
인터랙션 가이드
IA
키스크린
플로우
(물론, 이 것 말고도 실제 들어가는 내용은 더 많거나 적다. 케바케)
1. 표지
표지는 필요한 내용만 간략하게 만들자. 여기에는 프로젝트 이름, 문서 버전, 작성 날짜, 작성자 또는 부서명이 들어가. 프로젝트 내에서 개별 서비스나 기능별로 문서를 분리한다면 프로젝트 이름과 함께 부제를 적어야겠지. 페이지가 많거나 서비스를 구성하는 단위가 여러 개일 때는 섹션으로 묶어서 중간중간 간지를 넣어줘. 그러면 원하는 페이지를 한 번에 찾기 쉬워지겠지. UX 디자이너라면 문서를 받아 보는 사용자도 배려할 수 있어야겠지?
2. 히스토리
히스토리를 남기는 페이지를 만들자. 그리고 f/u으로 버전이 올라갈 때마다 그때 발생한 수정사항을 적어. 그러면 언제, 누가, 무엇에 의해 어떻게 내용이 업데이트됐는지를 추적할 수 있게 되지. 이것만 3장, 5장 넘어가는 경우도 종종 있으니까 테이블 높이는 알아서 줄여 놓자….
3. 목차
다음은 목차 페이지를 만들자. 목차는 문서에 어떤 내용들이 작성되어 있는지 각 페이지 제목이나 화면 이름을 순서대로 나열한 페이지야. 아직 작성이 덜 된 페이지를 구분하거나, 수정 또는 삭제, 새로 만든 페이지를 목차에 직접 표시할 수도 있어.
4. 인터랙션 가이드
이것은 화면의 구성 요소나 인터랙션을 설명하기 위해 사용한 보조 수단에 대한 가이드 페이지야. 예를 들면 탭과 더블 탭, 스크롤은 어떻게 표기했는지, PC인 경우 클릭과 우클릭, 마우스 호버는 어떻게 표기했는지 등을 설명하는 거지.
5. IA
말 그대로 IA. Information architecture인데 경우에 따라 생략하는 경우도 있어.
6. 키스크린
UI 기획자가 수행한 그동안의 결과가 구체화된 결정체! 키스크린을 구성하는 페이지에는 보통 디자인 소스가 입혀지지 않은 화면과, 화면의 구성 요소에 대해 정의하는 디스크립션이 포함되어야 해. 화면을 그릴 때는 혼돈의 여지가 있는 컬러 사용은 최대한 자제하고 레이아웃과 인터페이스를 표현하는 데에 집중해야 해. 여기가 고정인지 유동 영역인지, 스크롤이나 버튼 선택, 입력했을 때 어떤 결과가 어떤 순서로 나오는지 등을 상세히 설명해 줘야 하지. 그러면서도 간결하게. 가장 쉽게 이해될 수 있는 방법으로.
화면 설계서는 개발자, 디자이너, 사업 팀 간의 커뮤니케이션을 위한 문서야. 같은 말이라도 각 역할자들은 서로 다르게 해석할 수 있거든. 그래서 기본적으로 애매모호하거나 사실이 아닌 가정이 들어가면 안 되고 액션과 피드백에 대한 인터랙션을 명확히 설명하는 게 필요해.
키스크린을 뽑는 과정과 방법은 프로젝트 상황에 따라 매우 다르지만, 정석은 이 글을 참고해 보길.
키스크린(Key Screens)이 나오기까지의 과정
7. 플로우
시나리오 혹은 워크플로우라고 불리는 이 페이지는, 앞서 작성한 키스크린을 가지고 만드는 내용이야. 인터랙션 표기와 함께 각각의 화면을 연결해서 어떤 방식으로 서비스가 흘러가는지, 사용자가 해당 기능을 어떤 순서로 쓰는지를 파악할 수 있게 하지. 스케치나 XD 같은 프로토타이핑 툴을 쓰면 보다 효과적인 전달이 가능하겠지. 4컷 만화와 움짤의 차이랄까?
일단 여기까지 보고 궁금한 게 있으면 또 얘기해 줘.
