UI 디자이너, 기획자의 습관 훈련법
스크린샷 찍기부터, 서비스의 뒷면까지 확인하는 실무작업 습관에 대해
좋은 UI 디자이너, 기획자는 실무작업과 조사과정을 통해 성장하게된다. 그렇다면 실제 실무와 조사과정에서 어떤 훈련방식이 필요할까? 오늘은 실무에서 꼭 확인해야하는 실무작업 습관에 대해 이야기해보도록 하겠다.
1. 스마트폰 OS : 안드로이드는 써보셨어요?
대부분의 UI 디자이너들은 아이폰을 사용하는 경우가 많다. 시각적 만족도나 OS 의 완성도 때문인 경우가 대부분인데, 이 경우 실제 개발환경과 일치하지 않는 UI를 만드는 경우가 대부분이다. 실제 상용화된 모바일 UI와 웹 UI 라이브러리는 iOS와 Mac OS가 아니라, 구글의 마테리얼 UI를 컴포넌트로 사용하는 경우가 대부분이다. 특히 모바일 웹과 앱의 경계가 많이 사라지고있는 현재, 이 부분은 더욱 중요해지고있다. 안드로이드 OS를 오랫동안 써보았는가에 따라 컴포넌트의 일반적인 형태나, 뒤로가기 등의 히스토리 처리 등에서 큰 차이를 겪기 때문이다.
물론 가장 좋은 방식은 iOS와 안드로이드 모두를 사용하는 것인데. 대부분의 사람은 하나의 폰을 주로 사용하게되어있다. 그러니 평소에 익숙한대로 기획, 설계를 해버리게되는 '습관'이 실제 실무에서도 큰 영향을 주게된다. 특히 iOS의 작은 텍스트 크기와 깔끔함에 익숙해진 사람은 국내 3040 세대가 사용하는 안드로이드 환경이 어떠한지. 텍스트 크기조절이 왜 필요한지 조차 인식하지 못하는 경우가 많다. 심지어 요즘은 앱 개발에 있어서 Flutter와 같은 크로스 플랫폼을 사용하게 되는 경우가 많다. 이 경우 안드로이드의 문법을 바탕으로 iOS까지 지원해야하니, 안드로이드의 중요성은 더욱 커질 수 밖에 없다.
(물론 안드로이드 사용자는 역으로 iOS를 써보거나, 타 OS를 가진 폰들도 써볼것을 권장한다.)
https://brunch.co.kr/@clay1987/154
2. 상상하지 말고, 직접 스크린샷을 찍어요
신입사원때 버릇이 잘못 들면, 나중에도 고생하게되는 것중 하나가 '자료찾기' 습관이다. 대부분의 사람들은 머릿속에서 이미 알고있는 것들을 바탕으로 화면을 설계하려고한다. 놀랍게도 UI 디자이너들 중에는 실제 서비스를 찾아서 실제 화면 스크린샷을 찍는 사람들은 그리 많지 않다. 이유는 여러가지지만, '귀찮음'이 가장 큰 이유다. 이미 본인 기준에서는 그 서비스를 '이해하고있다고 생각'하기 때문인데, 이 습관이 생각보다 많이 문제가 된다. 특히 iOS 기준으로 스마트폰을 사용하는 사람이 '상상'으로 설계를 진행할 경우. 문제는 두배, 세배 이상으로 커지게된다.
일부 OS에서는 긴 화면도 한번에 스크린샷을 찍는 기능을 제공하기도한다스크린샷을 찍어야하는 이유는 일단 '실제 타사 서비스'에서 사용하고있는 비례와 들어가는 정보를 파악하기 위해서다. 본인이 정말 천재가 아닌 이상, 대부분의 기획자는 서비스에 들어가야할 정보들을 놓치게되기 마련이다. 그런 상태에서 '상상'을 통해 설계를 진행할 경우, 중요한 입력정보나, 추가정보들을 빠뜨리게되는 경우가 생긴다. 그러니 가능하면 타사 서비스를 바탕으로 '어떤 정보가, 어떻게 들어가야할지'를 파악하고, 그것을 재배치해보는게 좋다. 물론 타사 서비스들이 완성도가 낮은 경우, 비슷한 정보가 들어가는 다른 서비스들을 찾아봐야한다.
실제로 많은 사람들이 '다른 사람이 찍은 스크린샷'을 검색해서 사용하는 경우가 많은데, 이 부분. 생각보다 위험한 행동일 수 있다. 실제 본인이 사용하는 스마트폰의 기준으로, 개별 정보를 파악하고 스크린샷을 찍어야한다. 그렇지 않으면, 변형되거나 기간이 지난 옛날 정보를 얻게될 가능성이 높기 때문이다. 이런 습관이 반복되는 경우, 당장은 괜찮아보여도 2년~3년 후에나 문제가 드러나게 된다. 새로운 레이아웃을 찾아보지 않으니, 다른 선택지가 있는지를 고민하지 않게 된다. 또한 자신이 자주 사용하는 서비스를 주로 따라하게 된다. 그 서비스들이 정말 잘 만든 서비스라면 몰라도, 대부분 기존의 단점을 그대로 반복 재생산하게될 가능성이 높다.
3. 기능별로 서비스 FLOW를 만들고 확인해봐요
실무에서는 일단 화면부터 만들고 시작하는 사람들이 많다. 하지만 FLOW 단위에서 개별 기능들을 확인하지않은 경우, 그 화면이 '쓸모없어질' 가능성이 높다. 그러니 일단 무작정 화면부터 만들지 말고, '어떤 단계에 걸쳐서' 어떤 정보들을 다루게되는지부터 계획을 짜야한다. 그 계획이 만들어지고나면, 실제 FLOW 차트를 바탕으로 빠진 지점은 없는지를 체크하고, 각 화면들을 만들어넣어 실제 내용을 확인해보면 된다. 이런식으로 단계별로 작업을 하더라도 여전히 '빠진 기능이나 정보'들이 생길 수 있기 때문에, 이런 지점을 뒤늦게 확인하게되면 개발팀과 감정 싸움을 하게되는 경우도 생긴다.
플로우 차트부터 만들고, 이후에 화면을 하나씩 얹어나가자가장 좋은 방법은 기능명세서 수준으로 '어떤 정보들이 들어가야하는지'부터 정리하고, 그 이후에 FLOW 차트를 작업하는 것이다. 다만 이 방식의 경우, '기능명세서' 자체에서 정보를 빠뜨릴 가능성이 있다. 그래서 내가 추천하는 방식은 '사용자 타입별로 사용해야할 기능'의 목록을 정리하고, 기능별 FLOW 차트를 만드는 것이다. 이 방식대로 할 경우, 주요기능과 보조기능을 쉽게 나눌 수 있고, 실제 클라이언트와의 커뮤니케이션도 훨씬 손쉽게 진행할 수 있다. 이후 화면을 만들면서 '빠져있는 정보는 없는지' 체크하는 형태로 작업하는 것을 권장한다.
4. 정보의 우선순위를 생각해보고, 순서와 배치를 정해요
페이지 단위에서의 정보정리. UI 컴포넌트 단위에서의 정보정리. 모든 UI와 화면들은 '정보'단위의 정리가 필요하다. 이 부분을 잘 하지 못하는 사람은 시각물을 만들 때에도 많은 약점을 갖게된다. 시안에서 너무 많은 정보를 보여주거나, 그루핑을 하지못해 어수선한 결과물을 만들게되기 때문이다. 대장이 되는 정보가 무엇이고, 그것에 연관되는 정보가 무엇인지. 이 서비스에서 해당 정보가 정말 필요한지 (빼버려도 좋은지). 외부에서 가져온 정보와, 입력시키는 정보를 어떻게 구분해줄지. 이런 '정보를 넣고 빼고, 그루핑해주는 과정'이야말로 UI에서 가장 중요한 작업이다.
이런 정보정리는 '우리에게 익숙하지 않은, 복잡한 난이도의 설계'에서 더욱더 중요해진다. 일반인의 입장에서 의료업계의 정보를 다뤄야한다거나. 부동산 전문가들이 보는 자료를 정리해야할 때. 의류업계 전문가의 정보를 정리해야할 때. 어떤 것들이, 무슨 기준으로 묶여야하는지. 또 어떤 정보는 '덜 중요하고, 필요하지 않은지'를 알아야한다. 그래야 우선순위에 맞게 정보를 정리할 수 있고, 비슷한 중요도를 가진 내용들을 '묶어서 보여줄 수 있다.' 또한 이런 정보의 위계질서 (hierarchy)는 다시 시각적 스타일이나 표현법으로도 연결이 된다.
체크포인트
- 중요한 타이틀은 굵게 표현하고, 그 내용의 하위정보는 들여쓰기하거나, 그루핑 처리해주기
- 비슷한 중요도의 정보를 보여줘야할 때는, 그것을 묶을 수 있는 서브타이틀을 사용하기
- 중요한 내용은 100% 투명도로, 그렇지 않은 정보는 50% 투명도로 쓰기
- 중요한 내용들 중에서도 '의미있는 숫자나 금액'은 색상을 사용하기
- 색상을 사용하는 데 있어서, 정말 필요한 경우가 아니면 무채색만 사용하기
5. 텍스트 스타일은 두가지만으로도 충분해요
일반적인 UI 디자인에서는 Bold 타입과 Regular 타입의 폰트만으로도 대부분의 정보를 표현해줄 수 있다. 정말 별도의 폰트가 필요한 경우라면, 숫자 등의 표기를 위해 별도 폰트를 사용하기도한다. 물론 상황에 따라 시각적으로 Medium 타입의 폰트를 사용하는 경우나, Thin 타입을 사용해야할 경우도 존재한다. 다만 이런 지점은 투명도를 조절하거나, bold 타입에 색상을 입히는 식으로도 대처가 가능하니, 가능하면 폰트 스타일을 줄이는 것이 좋다. 가장 큰 이유는 폰트가 다양할수록 프론트엔드 웹 / 앱 개발자가 처리해야할 스타일의 양이 늘어나기 때문이다.
실무에서 쓸 수 있는 폰트중에는 다양한 굵기를 지원하는 폰트가 별로 없다실제 개발 환경에서는 대부분의 컴포넌트를 일일히 개발자가 만들어야하고. 커스텀한 디자인 시스템을 활용할 시간이 없는 경우가 많다. 정말 거대한 규모의 프로젝트이고, 기간이 충분하다면 몰라도 - 디자인 시스템 레벨까지의 내용을 다루기엔, 개발자들이 해야할 일이 너무 많다. 또한 개발할 내용이 많은 경우, 커스텀 디자인시스템보다, 별도의 상용화된 UI 라이브러리를 사용하는 것이 훨씬 효율적이다. (물론 이런 라이브러리는 대부분 구글의 마테리얼 UI를 바탕으로 만들어진 것들이다.) 본인이 작업하고있는 프로젝트가 개발중심의 프로젝트라면, 특히 스타일에 대한 부분을 너무 다양하게 만들지 않도록 주의하는 것이 좋다.
-
이외에도 실제 문서작업을 할 때나, UI 디자인을 해야할때 챙겨야할 지점들이 많다. 다만 이곳에서 모든 내용을 다루기엔 무리가 있을듯 하다. 추후에 다른 기회가 있다면 다른 추가적인 내용들도 다뤄볼 예정이다.
