은행에서 디지털뱅킹에 대한 전략을 세우고, 연구하고, 개발하고, 유지보수하는 게 나의 일이다. 대기업이 그렇듯이 명목상으로 부서와 팀을 나눠주긴 했으나 서로 비슷비슷하고 겹치는 업무가 많아 수도 없이 합종연횡하는 조직개편을 시도한다.
과거 CBD방법론으로 프로젝트를 시작한 게 나와 IT의 인연인데, 중간에 한참을 떨어져 있다 이곳에 약 4년전에 오면서 다시 IT에 더해 디지털 대고객 서비스 채널 관련된 업무를 하고 있다.
지난 주 토요일 정보처리기사 실시시험을 보았다. 이 나이에 갑자기 무슨 정보처리기산가 싶지만 어느날 우연히 보게된 시험의 커리큘럼이 너무 맘에 들어 시험을 신청했다. 신청 후 자세한 시험과목과 시험방식, 그리고 컴공 졸업생들이 볼 수준의 내용이라 꽤 쉽지 않다는 사실을 알게 되었지만, 공부하는 내내 매우 도움이 되었고 배운 게 많았다. 지난 기간동안 소프트웨어 공학이니 아키텍처니 DB니 하는 것들이 이상하게 재밌더니...결국 조금씩의 예습이 되었다.
금융DT테스트라는 시험의 스터디를 2개 운영하면서 공부를 해야해서 조금 피곤하긴 했어도 어찌되었든 지난 주 실기 시험(고작 20문제인데 90분 가까이를 써야했다.)을 보았고, 항상 그렇듯 한두 문제로 당락이 결정될 것 같다. 11월 26일이던가에 결과가 나오니 그냥 잊고 있어야겠다.
정처기에는 워낙 많은 내용이 나오고, 하나하나가 아카데믹한 주제들인데, 그 중 오늘은 UI 원칙이라고 하는 4가지에 대해 한가지씩 적어본다.
먼저 정처기에 나온 4가지 원칙은 아래와 같다.
유학유직(有學有直, 배움이 있어야 바를 수 있다.)으로 외우면 된다. 요건 정처기 시험보려고 내가 만든 거니 오해는 말고.
1) 유효성 (Efficiency)
- 정확하고 완벽하게 사용자의 목표가 달성될 수 있도록 제작
2) 학습성 (Learnability)
- 초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 제작
- 쉽게 학습 (Easy of learning), 쉬운 접근 (Accessibility), 쉽게 기억 (Memorability)
3) 유연성 (Flexibility)
- 사용자의 인터랙션을 최대한 포용하고, 실수를 방지할 수 있도록 제작
- 오류예방 (Error Prevention), 실수포용 (Forgiveness), 오류 감지 (Error Detectability)
4) 직관성 (Intuitiveness)
- 앱의 구조를 큰 노력 없이도 쉽게 이해하고, 쉽게 사용할 수 있게 제작해야 함
- 용이한 검색 (Findability), 쉬운 사용성 (Ease of use), 일관성 (Consistency)
모두 한글이라 사전적 의미를 이해하는 데 별 문제는 없다. 그리고, 모든 인터넷 회사들이 당연히 이런 기준을 지키며 서비스를 만들고 있을거라 생각을 할 것 같다. 그런데 실제 UI 기획을 하고, 고객용 서비스를 만들다 보면 결코 어느 원칙 하나도 제대로 지키긴 쉽지 않다는 걸 알게 된다.
간단하게 하나씩 따져보자.
먼저 유효성이다. UI, 즉, 화면을 만난 사용자가 자신의 목표가 달성될 수 있도록 구성(디자인, 배치)이 되어야 한다는 것이다.
가장 단순한 기능을 예로 들기 위해 고객이 핸드폰 번호를 입력받는 기능을 생각해보자.
010-1234-5678
이를 위해 기획자는 최소한 아래와 같은 질문을 하게 될 것이다.
화면에 핸드폰 번호라는 텍스트가 있고 텍스트박스가 3개 있는 형태가 나을지,
3개의 텍스트박스를 사용한다면 첫번째 텍스트박스에 010 등등의 국번을 세팅하는 게 나을지,
플레이스홀더가 있는 하나의 텍스트박스가 나을지,
만약 플레이스홀더를 사용한다면 깔끔하게 그냥 밑줄만 있는 건 어떨까?
https://en.wikipedia.org/wiki/Graphical_widget
여기에 더하여 한글이나 영문, 특수문자 제어나, 최대 입력가능 자릿수, 그리고, 잘못 입력된 경우에 대한 처리도 기본적으로 고려가 되어야 유효성, 즉, 목표달성이 될 것이다.
거기다 입력을 받는 게 고객에게 어떤 느낌으로 다가가는 일(UX)인지에 따라 UI를 조금씩 달라질 수 있다.
당연히 앱이나 웹에서 제공하려는 서비스의 성격이나, 다른 화면과의 조화는 기본일테고, 핸드폰번호를 입력받는 테이블의 자료형도 알아야 한다.
대상 테이블의 칼럼이 character형인지, varchar형인지, 대시(-)를 포함해서 넣는 형태로 테이블이 만들어져 있는 지, 3개의 값을 따로 칼럼으로 정의되어 있는 지, 빈값도 허용할 지 등의 데이터까지 고려되어야 겉으로 드러난 목표 뿐만 아니라 실질적인 목표달성이 이루어 질 수 있다.
여기에 마지막으로 하나만 더해보자. 데이터가 정상적으로 저장이 실시간으로 이루어진다면 문제가 없지만, 그리고 즉각적으로 고객에게 알려준다면 문제가 없다면, 혹시 데이터베이스 상의 문제(또는 다른 어떤 사악한 이유)로 데이터가 저장에 실패했다고 하자. 하필 고객은 그 에러메시지를 보지 못하고 서비스(앱이나 웹)를 닫았다면 어떻게 해야 할까?
다음 번 로그인 할때 알려줄 것인지, 인지하는 그 순간 Push 등을 통해 알려줄 것인지.
기획경험이 쌓이다 보면 이 많은 규칙과 가이드, 각종 규칙이 몸에 배어 자연스레 기획서에 반영이 된다. 물론 한두개가 빠지기도 하고, 과거엔 고려하지 않던 기준이 추가되는 건 당연한 일이다.
하지만, 위에 적은 것만 봐도 "유효성"이라는 원칙에서 지향하는 사용자가 UI만으로 목표를 달성한다는 건 이만큼 어려운 일이다.
안타까운 건 내가 본 많은 "현업" 기획자들은 개발자가 다 알아서 해줄 것이라 생각하고 화면기획을 하는 경우가 부지기수다. 특히 회사의 규모가 커지고, 조직이 계층조직이고, 회사대 회사의 IT아웃소싱인 경우라면, "핸드폰 번호가 입력된다."라는 한줄이 기획이 되는 경우가 많았던 것 같다. 문젠 그런식의 기획에 익숙해진 개발팀은 그 한줄과 한두번의 회의로 서비스를 구현한다. 당연히 멀리서 보면 그럴 듯 하지만 한걸음 한걸음 다가갈수록 기획자의 머리속에 그렸던 결과물과는 점점 멀어진다.
휴...겨우 하나의 원칙에 대한 얘길 하는데도 쉽지가 않다.
"학"은 다음에 하는 걸로.
참! UI가 반드시 폰과 웹이라고 생각하진 않겠지만, 혹시나 하여 덧붙인다. UI는 마우스, 키보드, ATM, 하물며 음성입력까지 모두 포괄한다. 시간이 된다면 CUI, GUI, NUI를 한번씩 찾아보시길.
해외사례 한가지 공유하고 마무리~
Adobe 사이트에서 제시된 4가지 원칙은 이렇다. (여기도 4가지네...)
자세한 내용은 아래 링크를 참조하길. 괄호안에 요약은 나의 기준으로 축약한 내용이라 너무 "축약"이 되어있다.
The UI design principals are:
Place users in control of the interface (사용자를 인터페이스 컨트롤에 두라. 무엇을 해야할 지 명확하게 알려주라는 의미, 즉 행동유도가 되어야 한다.)
Make it comfortable to interact with a product (상호작용의 첫번째는 간결함으로 꼽고 있다. 금융사의 앱을 보면 한상 가득한 느낌이다.)
Reduce cognitive load (헷갈리게 하면 안된다. 고객이 무엇을 해야할지 인지하는데 리소스 낭빌 하게 하면 안된다.)
Make user interfaces consistent (일관성이 중요하다. 뭔가 실행하는 컨트롤(위젯 또는 엘리먼트)이 여기선 동그란 버튼, 저기선 사각버튼, 여기선 빨간색이 취소, 저기선 검은색이 취소가 되면 안된다.)
https://xd.adobe.com/ideas/process/ui-design/4-golden-rules-ui-design/
'2-minutes lecture' 카테고리의 다른 글
마이크로 인터랙션 톧아보기 (0) | 2021.10.25 |
---|---|
와이어프레임, 목업, 프로토타입, 스토리보드 구분하기 (0) | 2021.10.22 |
SRE 이해하기 (Site Reliability Engineering, feat.DevOps) (0) | 2021.10.21 |
API vs. BaaS vs. Embedded Finance (0) | 2021.10.20 |
Global PEF (초보자 가이드) (0) | 2021.09.29 |