brunch

매거진 UI 디자인 연구

라이킷 59 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 리플러스 Feb 03. 2023

UI 설계, 실무에선 어떻게 하세요?

실무에서 UI 설계할때, 저는 이런 방식으로 합니다

지금까지 UI 설계나 디자인 관련해 이론적인 부분을 많이 다뤄왔다. 하지만 실무에서는 이런 지점을 다 체크하기는 어렵다. 그래서 오늘은 내가 실제로 UI 설계를 하는 방법을 다뤄보려한다. 실무에서 꼭 해야하는 지점만 짚어 다루는 내용이니, 이론적으로는 잘못된 방식일 수 있다. 다만 이 사람은 이렇게 작업하는구나, 정도의 참고용으로 이해하면 될 것 같다.

UI 디자인을 해야하고, 설계를 잡아야할때. 나는 가장 먼저 사용자 타입을 확인한다. 어떤 사용자 타입이 존재하는지.그리고 그들이 무슨 역할을 하는지. 어떤 주요기능을 써서, 어떤 단계를 통해 그 서비스가 이뤄지는지를 정리한다. 대부분 FLOW 차트를 만들지만, 내용이 복잡한 경우 텍스트로 줄줄이 내용을 써본다. 커머스의 예를 들자면 이런식이다.

판매자가 상품을 등록한다 -> 구매자가 상품을 보고, 구매요청을 한다. -> 판매자가 구매요청을 확인한다. -> 판매자가 제품을 배송한다 -> 구매자가 상품을 받아본다. -> 리뷰를 쓰거나, 쓰지않는다.

프로세스가 어려울수록 FLOW 차트를 만들어 전체 과정을 정리해본다

복잡한 검색 화면이나 회원가입같은 세세한 내용은 생각하지 않는다. 이미 모든게 준비된 상태에서 가장 중요한 아이템을 다루는 지점을 주로 정리한다. 이후에 이 지점을 FLOW 차트로 그려보면서, 각각의 단계에 빠져있는 지점을 채우기 시작한다.

- 상품등록은 어떻게 하는지 (상품등록 관리자? 엑셀시트?)

- 상품은 어떻게 보는지 (검색목록? 상세화면?)

- 구매는 어떻게 하는지 (간편결제? PG사 API?)

- 구매요청은 어떻게 확인하는지 (알림톡? 전화?)

- 배송은 어떻게 처리하는지 (직접배송? 택배사 대행?)

- 상품을 받았다는건 어떻게 아는지 (상품받았음 클릭? 배송사진? 자동처리?)

- 리뷰는 어떻게 쓰고, 또 어떻게 공개하는지 (리뷰에 들어가는 정보기준은? 리뷰 공개는 바로 처리하나?)

대충 이정도 단계를 다루다보면, 핵심적인 FLOW는 나오게되고, 거기에 들어가는 핵심 정보들의 '상태값'들이 나오게된다. 상태값은 대부분 특정 '대상'의 값이 바뀌면서, 서비스가 진행되는걸 말한다. 그 대상은 배송상태가 될수도 있고, 작업진행상태가 될 수도 있다. 연속적으로 무언가가 이뤄지고, 그것에 따라 알림이 발생하거나, 보여줘야할 정보가 달라지니. 주요 아이템과 상태값에 대한 부분을 따로 떼어서 따로 정리하는 편이다.

상태값은 대부분 특정 시점에서만 변한다. 그러니 그림으로 정리하는게 이해하기 좋다

주요 서비스 FLOW와 세부적인 내용들을 정리했고. 주요 대상의 상태값까지 잡고나면, 사실상 서비스의 핵심을 다 이해한 셈이다. 이때부터 레이아웃에 대한 고민에 들어간다. 대부분 비슷한 타사 서비스를 찾아보거나, 그 업계에서 가장 잘 만들어진 서비스를 벤치마킹하는 편이다. 그리고 그 과정에서 그들이 만들어둔 화면과 그 안에 들어가는 기능들을 쭉 살펴본다. 나중에는 내가 생각한 핵심 FLOW와 해당 서비스의 FLOW 단계를 비교해본다.

- 내가 생각한 핵심 FLOW

- 잘나가는 서비스의 FLOW 단계

그 차이점을 비교해보면, 대부분 그 서비스는 '자신들만의 특이한 상황' 떄문에 특정 정보나, 부가적인 화면들을 제공하게된다. 대부분의 경우 이런 내용들은 똑같이 따라할 필요가 없으니 과감히 잘라낸다. 대신 그 과정에서 쓸만한게 있으면 추가하거나, 그대로 살리려고 하는 편이다.

기획서 화면 예시. 실제 화면 설계서는 가능한 실제 비례에 가깝게 처리한다

화면단 기준으로는 생각해야하는게 항상 두가지가 있다. 하나는 정보를 어떻게 가져오는가에 대한 부분이고. 다른 한가지는 이 화면을 구성하는 관리자단이 필요한가에 대한 부분이다. 정보를 가져오는 지점은 API로 땡겨오던, 사람에게 입력시키던, 무언가를 조합하건 간에 그 정보가 '만들어지는 기준점'을 살피는 편이다. 그 값들이 고정된 형태라면 데이터베이스 (DB) 설계할때 들어가야하는 내용들이다. 특히 이런 내용들은 상태값하고도 연관이 깊다. 이와 반대로 변동될 수 있다면 대부분 string (텍스트 뭉치) 형태의 입력값인게 대부분이다. 바뀔수 없는 형태의 데이터가 대부분 더 중요하고, 변동될수 있는 지점은 신경쓸 일이 많지 않다.

관리자 화면은 내용이 많다보니 테이블 (표) 형태를 사용하는 경우가 많다

화면을 구성하는 관리자단에 대한 고민은 대부분 CMS와 연관이 있다. 컨텐츠 매니지먼트 시스템. 그러니까 하드코딩된 정보를 냅다 보여주던가, DB에서 끌어와서 고정된 값을 보여준다던가 하는게 아니라는거. 관리자가 어떻게 처리하느냐에 따라 내용이 바뀔 수 있다는 이야기다. 특히 포탈서비스나 커머스서비스 같은. 다양한 업체나 정보가 함께 공존하는 서비스들은 이 관리자단이 정말 중요하다. 커스터마이징을 다른사람이 하게되니, 각각의 정보를 어디서 끌어와서, 무얼 보여줄지를 하나하나 생각해봐야한다.

개인적으로 관리자단이 복잡할수록 운영인력이 고생한다고 생각하는 편이라. 레이아웃이나 정보 배치에 많은 자유도를 주진 않는다. 정해진 템플릿대로, 내용만 입력하면 바로 확인할 수 있게 만드는게 낫다고 본다.

화면 디자인에서 가장 자주 사용하는건 직접 찍은 스크린샷이다. 일단 스샷을 찍어서 좌우 간격부터 확인한다. 720이나 360 사이즈 기준에서 좌우 간격의 최소단위가 어느정도 되는지. 도형적으로 안정적인지 같은걸 박스를 그려서 확인해본다. 그러고나서 괜찮으면 레이아웃은 건드리지 않고, 불필요한 UI만 잘라내는 식으로 설계를 진행한다.

디자인적으로 독특한 형태를 띄어야하는지 생각하기보다. 전체 프로세스에서 논리적으로 문제가 없을지를 더 깊게 보는 편이다. 화면이 비슷해도 내부 UI 요소가 달라지면 화면은 달라보이기 마련이니까. 시각적인 지점은 크게 고민하지 않는 편이다. 그러나 정작 작업하면서 UI 배치나, 정보 그루핑에 따라 레이아웃을 변경하는 경우가 대부분이다. (결국엔 나만의 고유한 화면들이 만들어지는 가장 큰 이유가 이 부분인것 같다)

스크린샷 기반의 정보분석. 뭐가 더 나은지 정리를 한 다음 벤치마킹 여부를 결정한다

내가 가장 먼저 만드는 화면은 메인화면이다. 전체적인 분위기도 볼 수 있고, 실제 내가 정리했던 주요 사용 FLOW의 시작점이니까. 내가 생각한 FLOW 구성이 문제가 없는지 하나하나 확인하는 느낌이다. 그러고나면 중요도가 덜한, 그 다음 단계의 화면들을 차례차례 만들어나간다. 회원가입이나 설정화면, 알림화면 같은건 가장 마지막에 작업한다. 별로 중요하지도 않을 뿐더러, 대부분의 앱이 비슷해서 고민할 필요가 없기 때문이다.

각 화면의 이해를 도울수 있게, UI를 떼어내 설명을 붙여준다.

대신 화면을 만들고나면, 개발자들에게 설명하듯이 화면 오른쪽에 '각각의 정보의 배치나, 기능'에 대해서 텍스트로 설명을 써놓는다. 화면만 갖고는 전체 FLOW가 눈에 안들어온다. 그리고 뭘 고민해야할지도 알기 어렵다. 고민이 필요한 지점은 빨간 글씨로 '이런점 고민해봐야함' 같은 메모를 남겨둔다. 처음에는 와이어프레임 수준의 작업만 진행하기 때문에, 진행속도가 꽤 빠른 편이다. 대신 비례만큼은 실제 스크린샷을 기반으로 요소별 박스 위치를 정리해두는게 좋다. 나중에 디자인할때 비례 새로잡기 귀찮아지니까.

이런식으로 화면 단위의 FLOW를 기획서 레벨로 마치고나면. 자잘한 화면들을 만들어주고. 각 화면이나 UI들에 상태값이나, 조건값 기준으로 나타나는 녀석들을 정리해준다. If / else 같은 내용들을 담아서 '무슨 조건일때 이 화면이나 UI가 등장하는지'를 정리하는 거다.이런게 끝나고 대부분의 작업이 끝나면, 그 때 이후부터 실제 화면별 디자인 요소를 덮어씌운다.

IF 기반 조건문을 사용한 사례. 2중, 3중으로 조건문이 붙는 경우도 있다

디자인 요소를 잡는건 세세하게 하지 않는다. 제대로 한다면 디자인 요소마다 간격도 확인하고, 다양한 고민을 해야하지만. 내 작업 우선순위는 '개발자가 내용을 이해하고, 그걸 개발할 수 있는가' 이다. 그러니 세세한 간격같은것보다 입력창의 입력제한 (영어만? 숫자만? 몇글자까지? 등등) 이라던가, 조건부로 등장하는 화면들의 정리 같은 것에 더 신경을 쓰는 편이다.

자잘한 팝업이나 추가/ 삭제같은 기능 들도 보통 이 시점에서 작업한다. 기획서 기준으로 보면 와이어프레임 작업때 처리해야하는 내용이지만. 실제로 빠르게 치다보면 팝업이나, 토스트 메시지같은건 까먹는 경우가 많다. 그러니 이런 지점에서 보여줘야되는 내용이 있는지 쭉 확인해보는거지. 이정도 까지만 오더라도 이미 실제 개발이 가능한 레벨의 작업이 완성된다. 여기에서 간격이나 세부적인 레이아웃을 조절할지, 시안 퀄리티를 올려야할지를 결정하는 편이다.

제일 나중에 하는것들 중 하나가 상태값에 따른 알림처리다. 알림 메시지는 실제 서비스 FLOW가 만들어지고 나서 하더라도 늦지않는데다. 개별 메시지 내용까지 담아줘야해서 생각보다 귀찮은 작업이다. 게다가 알림 메시지를 눌렀을 때 이동하는 화면들도 일일히 넣어줘야해서. 작업 밀도가 높은데 비해 별 보람이 없는 기능이기도 하다.

대부분의 알림은 구분값과 내용, 변수명 같은 것들로 이뤄진다. 양이 많으니 엑셀로 작업하는게 편할것이다.

가장 문제가되는 지점들 중 하나는 특정 화면에 알림을 눌러 들어갔는데. 다시 뒤로가기 버튼 (안드로이드)을 누른 경우. 해당 처리를 어떻게해야하는지 하나하나 정리해줘야한다는 거다. 아이폰 유저들은 상관없겠지만, 안드로이드는 이런 지점들까지 챙겨줘야해서 머리아픈 경우가 많다.

이런 알림 내용들은 앱 PUSH 말고도 알림톡 등을 사용하기도하는데. 이 경우 알림톡 관리 사이트에 들어가서 일일히 메시지 내용과 변수값을 하나하나 써줘야한다. 하나 수정하고 등록할 때마다 카카오 대행사 측에서 확인을 해야하니, 오타라도 하나 나면 수정하기가 쉽지 않다. 그래서 가장 마지막에 작업하는 편이다.

카카오비즈니스

비즈니스, 톡처럼 쉬워지다.

business.kakao.com

이쯤되면 이제 개발이 진행되고있을 거다. 간간히 개발자들이 요청하는 빠진 지점 추가해주고, 다른 작업들 하다보면 스마트폰으로 확인을 해볼 수 있다. 이때부터는 QA를 위한 작업을 준비해야하고. 필요한 경우 QA 시나리오를 작성해서 미리 전체 QA를 준비하기도한다. 다른 작업이 생기는 경우 일단 다른 작업으로 넘어가서 1번부터 다시 새로운 작업을 진행하는 경우가 많다.

실무 작업에서는 목적이 명확하다보니 별다른 고민이 필요없는 경우가 많다. 그러니 의식의 흐름대로, 빠르게 빠르게 쳐내는 지점을 목표로 잡는 편이다. 이렇게 보니 굉장히 대충 일하는 것 처럼 보일수도 있겠지만, 실제 작업시에는 저런 단계를 며칠에 걸쳐서 진행하게되니. 축약이나 생략된 부분들이 많을거라고 본다. 다만 이런식으로 전체 작업 내용을 다루는 것도 도움이 될듯 하여 정리해보았다.

아마도 이 자료를 바탕으로 추후 설계 관련 교육을 진행하지않을까 싶다.

keyword