UI 디자인 & 평가(Review)

 

UI 흐름(Flow) 정의

UI Flow 작성

와이어프레임(Wrieframe)을 작성하기 전에 UI Flow를 먼저 작성하는 것이 중요하다.

UI Flow를 작성해야 디자인 프로젝트를 마감할 때까지 몇 개의 화면과 컴포넌트들을 만들어야 하는지 알 수 있고, 업무의 범위와 디자인하는데 필요한 시간을 파악할 수 있다.

UI Flow 생략

기존의 서비스 업데이트라면, 업데이트의 범위에 해당되지 않는 부분을 체크한다.

Flow 업데이트

실제 해야 하는 디자인 업무가 무엇인지 명확하게 볼 수 있는 형태로 다듬는다.

이해 관계자(Stakeholders) 리뷰

리뷰를 생략하고 디자인을 진행하는 경우도 있지만, 가능하면 UI Flow를 정하는 시점부터 리뷰를 진행하는 것이 문제점을 빨리 파악하고 수정사항을 반영할 수 있다.

 

 

UI 디자인

디자인 시스템 확인

Figma, XD 등 업무에 활용하는 시스템에 맞는 Google Design Kit을 다운로드한다.

또는 SAP Fiori 디자인 가이드라인에서 어느 플랫폼에 올라가는 디자인인지 항목을 선택하면 그에 맞는 리소스를 다운로드할 수 있다.

 

디자인 시스템 사용

리소스 Kit에서 알맞은 다운로드 Kit을 받으면 클라우드에서 바로 사용하거나, 로컬에 다운로드하여 라이브러리 파일을 등록해 사용할 수 있다.

베이스로 기본 컴포넌트를 가져오지만 보통은 그대로 사용하지 않고, 디자인 시스템이 허용하는 범위 안에서 회사의 서비스 컵셉과 어울리도록 재구성한다.

 

실제 화면으로, 지원해야 하는 정보와 기능들이 어떻게 진행되는지 디자인해 본다.

Task flow로 보는 것보다 UI flow로 보게 되면 사용자가 어떻게 사용할지 흐름을 확인할 수 있고, 요구사항이 잘 반영되었는지 화면으로 확인할 수 있다.

 

 

UI 리뷰

만들어진 시스템이 사용자가 잘 사용하도록 만들었는지 UI 검증을 진행한다.

UI를 사용자가 잘 사용할 수 있도록 디자인하고 개발되었는가를 확인하며, 다음과 같은 사용성 평가 과정을 진행한다.

사용성(Usability) 평가

다음과 같은 평가를 거쳐 UIUX의 좋고 나쁨을 알 수 있다.

1. 내비게이션 (Navigation)

UI가 사용자가 이루고자 하는 목적을 잘 찾아갈 수 있게 필요한 버튼 등을 잘 제공하고 있는가를 확인한다.

2. 친숙도 (Familiarity)

UI가 사용자에게 얼마나 친숙한지 확인하는 과정으로, 제품이나 시스템이 익숙한 형태로 작동하는지 확인한다.

친숙할수록 초기 학습도가 낮게 사용할 수 있다.

3. 일관성 (Consistency)

하나의 제품, 하나의 시스템 안에서 동일한 기능은 동일한 방식으로 제공되는지 확인한다.

4. 오류 예방 (Error Prevention)

시스템에서 '계정 탈퇴', '글 삭제'와 같이 중요도를 갖고 있는 기능은, 사용자가 실수로 누른 게 아닌지 다시 한번 확인하는 등 가능한 한 사용자가 실수를 하지 않도록 배려해야 한다.

5. 피드백 (Feedback)

시스템에서 적절한 피드백이 없으면 사용자의 입장에서 불안함을 느낄 수 있다.

피드백(딜레이 표시 등)을 해줌으로써 사용자는 요청한 작업이 수행되고 있다고 인식할 수 있다.

6. 시각적 명료성 (Visual Clarity)

화면 안에 보이는 것들이 서비스의 의도대로 사용자에게 시각적 의미를 정확히 전달하는지 확인한다.

7. 유연성 (Flexibility)

사용자가 시스템을 이용해 얼마나 다양한 과업을 행할 수 있는지, 시스템은 얼마나 다양한 기능을 제공할 수 있는 구조인지를 확인한다.

8. 효용성 (Efficiency)

UI가 사용자에게 얼마나 효용성 있고 유익한지를 확인한다.

 

어느 시스템에 적용하냐에 따라 UI의 멘트가 달라질 수 있다.

예를 들어, SNS는 말랑하게, 은행 앱은 약간 딱딱한 멘트를 적용하는 게 어울린다.

SNS의 경우 오류 표시와 직접적인 시스템의 오류 문구를 보여주는 것보다 가볍게 문구를 표시하고 다시 시도를 하도록 요청하는 것이 사용자의 입장에서도 좀 더 가볍게 받아들일 수 있다.

금전이 왔다 갔다 하는 은행 앱 같은 경우 오류가 일어났을 때 가벼운 문구를 사용한다면 사용자의 입장에서 예민하게 받아들일 수 있으니 상황에 맞는 톤을 사용하는 것도 중요하다.

 

이전에 사용한 항목을 먼저 보여주는 등 사용자가 빠르게 과업을 수행하기 위한 편의가 제공되는지,

로그인 시 입력 실수가 있을 때 어느 위치에서 실수가 있었다는 표시를 정확히 해주는 솔루션이 있는지,

중복 없이 일관된 메시지를 명확히 전달하고 있는지,

읽어야 하는 사항을 작은 화면에서도 문제없이 확인할 수 있는지,

각 컴포넌트의 최소 사이즈를 지키면서 오브젝트는 사용자가 잘 인지하고 편하게 읽을 수 있는 구조인지 등

UI 리뷰를 통해 이러한 사항들을 확인할 수 있다.

 

예외 케이스

사용자 테스트를 진행하면 '사용자를 어느 수준으로 기준을 잡아 만들었는가'에 따라 다양한 상황들이 나타날 수 있다.

제품에 대한 기본 지식이 부족해 사용을 전혀 못한다거나, 반대로 제품에 관한 전문가라 추가적으로 프로페셔널한 기능을 요청하는 경우들이 예외 케이스에 해당된다.

이렇게 대다수의 사용자들에서 약간 벗어난 사용자들을 어떻게 케어할 것인가를 고려해야 한다.