본문 바로가기
UI 디자인 연구

UI 설계 개선하기 : 방송통신대학 - 일정화면

by 리플러스 2021. 2. 2.
728x90

 

이미 기획서가 만들어진 상황에서는 정보를 시각화하는건 그리 어렵지 않습니다. 그러나 반대로 기획서도 없이, 기존의 서비스를 개선해야한다면 어떻게 해야할까요? 오늘은 실제 서비스 사례를 통해 설계를 개선하는 과정을 진행해보겠습니다.

 

* 이번 글에서는 정보정리 단계부터 시작해 UI 프레임워크를 만드는 과정을 포함하고 있어, 정보정리 훈련이 되어있지 않은 분이라면. 따라가는데 어려움을 느끼실 수도 있습니다.

 


 

1. 문제 발견하기

최근에 저는 방송통신대학교에 입학하게 되었습니다. 그런데 일정 내부에서 제가 직접 확인해야하는 '학생 입장에서의 출석, 시험, 강의시작 등'의 정보를 전혀 얻을수없었죠. 보여주는 정보는 분명 많은 것 같은데. 실제 사용자 관점에서는 쓸모없는 정보가 더 많았습니다.

 

이걸 정말 보라고 만들어둔건가요...?

 

 

-  사용자가 정말 봐야하는 정보들이 왜 나와있지 않은걸까?
-  그 정보를 보여주는 방식이 왜 하필 전체 달력 뷰 형태인걸까?

 

누가, 어떤 수업을, 언제 들어야하는지. 그게 가장 중요한 정보죠.

 

일단 사용자가 봐야하는 정보는. 달력기준에서는 출석이나 시험, 강의시작일 등의 일정 정보입니다. 수강신청시작 및 종료일자나, 수강료 결제일 등도 확인해야하죠. 그런데 정작 눈앞에는 그런 정보들이 보이질 않습니다. 게다가 달력뷰 형태에, 일일 정보가 아니라. 기간별 정보가 줄줄이 이어지다보니, 내용을 확인하기도 매우 어려웠습니다.

 

달력 뷰의 문제점. 여러 아이템들을 따로따로 보기엔, 너무 정신없는 방식.

 

일단 이런 캘린더 뷰를 선택한 것 부터, 잘못된 방식이란 생각이 들었습니다. 사용자가 실제로 봐야하는 정보가 기간 뷰가 아니라. 일별 수업 뷰라는걸 생각했을 때. 달력뷰는 지금 상황에는 맞지 않는 형태였죠. 게다가 정보의 기준을 사용자가 필터링을 켜거나, 끌 수 없다는 것도 문제였습니다. 그러니 일단 두가지 해결책이 필요했습니다.

 

-  일단 캘린더뷰를 대체할 수 있는 뷰 형태를 찾아내고
-  정보를 사용자가 켜고 끌 수 있도록, 필터링 개념을 추가하자

 

 

 

2. 해결방법 찾기 : 캘린더 뷰 VS 타임라인 뷰

일정을 표기하는 방식에는 크게 두가지가 있습니다. 첫번째는 달력뷰 기반으로 일정을 보여주는 것이고. 또 한가지는 타임라인 기준으로, 일정이 있는 날만 보여주는 방식이죠. 달력뷰는 반복되는 일정을 확인할 때 더 유리하고. 반복이 아닌, 랜덤한 값에는 적합한 방식이 아닙니다. 일단 불필요한 '비어있는 날짜'들을 계속해서 봐야하니. 화면 낭비도 심해지죠. 

 

구글 캘린더 사례 : 달력 뷰는 일정을 보기보다, 추가하고 편집하는 기능에 더 적합하다

 

실제 구글 캘린더 사례를 보면, 해당 날짜를 클릭하는 즉시 일정추가 화면이 뜹니다. 다른 사람이 만든 일정을 불러오거나, 편집할 수 있기 떄문인데. 대학의 일정은 상황이 전혀 다르죠. 대학의 학생은 전체 일정을 사용자가 다룰 필요가 없습니다. 관리자 쪽에서 주는 정보만 확실하게 볼 수 있으면 되죠. 

 

 

 

서비스의 상황에 맞게, 각각 다른 해결책이 필요합니다

 

달력뷰는 반복되는 대량의 기간을 관리하기에 좋은 방식입니다. 그에 반해 타임라인 뷰는 편집보다, 단순 내용 확인에 더 최적화 되어있죠. 내용이 많아진다면 보기가 어려워진다는 단점이 있지만. 필터링을 적용하면 별로 문제가 되지 않습니다. 지금같은 상황에는 딱 맞는 방식이겠군요?

 

 

타임라인 뷰 형태로 일정을 볼 때 어떨지, 자료를 찾아봤습니다

 

타임라인 뷰는 두가지 특징이 있습니다. 기간이나 날짜보다 개별 이벤트를 기준으로 정리가 된다는 것. 그리고 사용자가 봐야할 정보가 상대적으로 적다는 것이죠. SNS 피드창을 생각하면 이해가 쉽습니다. 실제로 대학의 학생들도 여러 수업 생산자를 팔로우하는 개념이니까요. 그러니 관련 공지나 내용들이, 빠른 시간 순서대로 쭈욱 배치되면, 훨씬 내용 확인이 쉬워지겠죠. 

다만 기간뷰 타입의 정보를 어떻게 보여줄것인지가 문제입니다. 개별 수업의 경우 일일 날짜로 정리가 되겠지만. 기간이 중요한 이벤트의 경우 한 눈에 보기가 어렵습니다. 단일 날짜 이벤트와, 기간별 이벤트를 동시에 놓는다면. 이 부분을 구분하기가 어려워질수도 있는 거죠. 이런 문제점을 어떻게 해결할 것인지가 또 하나의 문제였습니다. 그래서 저는 그 기간이 '시작되는 지점에' 하나의 카드를 보여주고. 끝나는 지점에 또다른 카드를 하나 보여주는 식으로 해결방안을 생각했습니다.

 

 

 

3. 해결방법 찾기 : 필터링을 위한 정보정리

기존에 방송통신대학교가 나누어둔 일정은 학사 기준의 일정과, 개인, 학과일정이 통합된 특이한 형태였습니다. 여기서 가장 큰 문제는 화면이 두가지로 나뉘어. 개인 출석과 시험정보는 '다른 페이지를 가서' 봐야한다는 거였고. 거기에도 물론 필터링 UI는 없었습니다. 

일정 안에 출석수업, 시험정보는 제공하지 않는다고요?

 

실제로 사용자가 알아야하는 정보는 대략 이런 정도였습니다.

-  내가 어떤 교과목 수업을 들어야하는지?
-  언제가 학기 / 수업 시작일인지?
-  언제 오프라인으로 방문을 해야하는지?
-  언제가 시험 날짜인지?
-  학기 종료 날짜는 언제인지? ... 등등

 

 

자, 그럼 바로 필터링 UI를 추가하면 될까요? 전혀 아닙니다. 실제 필터링을 표기하기 위해서는 - 일정 타입들에 어떤 정보들이 담겨있는지를 확인해야합니다. 그 정보들을 쭉 나열한 이후, 필터 UI로 처리할 것과. 카드 내부에서 분류로 표기할 것들을 나누어야하죠. 그래서 맨 처음 시작한 것은. 사용자에게 가장 필요한 정보가 무엇인지 정리해보는 작업이었습니다.

 

생각보다 담아야할 정보가 상당히 많아보이죠?

 

UI 디자인과 설계는 정보의 우선순위를 잡고. 유사한 것들을 묶어주는 과정이 꼭 필요합니다. 이 수많은 정보들을 어떤 순서로 묶고, 연결을 해줘야 사용자가 인식하기 편할까요? 사실, 그 과정은 간단합니다. 다른 사람에게 설명을 하듯이 이야기를 해보는 거죠.

1 월 1 일에는 OOOOO 수업이 있는데. 그 수업 이름은 뭐고, 그 수업은 3학년이 듣는 전공 수업이야. 이날 온라인 강의로 이뤄지니 참고해두라구. 

 

 

 

정보를 다시 묶어 단계별로 정리하는 과정

 

-  사용자가 몇 학년이고, 어떤 과인지 알아야하고
-  이 사람이 어느 날짜에 무슨 수업관련 이벤트가 있는지 알려줘야하는데
-  이 사람이 듣는 강의가 어떤 이름인지
-  그 강의의 시험인지, 수업인지도 알려줘야하고
-  그 강의가 오프라인 수업인지 아닌지
-  학년이 다르거나, 타 과 수업을 신청한 경우, 이 부분도 포함해주고... 등등

 

강의와 일정 관련 정보는 분류가 생각보다 쉽습니다. 그러나 대부분의 경우, 실제 정보정리 과정은 이것보다 훨씬 복잡합니다. 이 시스템 내에서 만들어질 수 있는 모든 가능성을 생각해야하기 때문이죠. 게다가 정보만 정리한다고 끝이 나는게 아닙니다. 다시 이 정보를 어떤 UI 형태로 표현해줘야할지. 정보 단위를 다시 나눠야하죠.

 

 

UI 단위로 표현하기 위해, 정보를 다시 묶어줍시다

 

여기에 정리된 정보들을 다시 풀어서 이야기해보자면. 다음과 같은 내용을 이야기해볼 수 있을겁니다.

 

이름 / 과 구분 / 학년 구분
-  사용자 정보는 시스템에서 배정되므로, 사용자가 바꿀 필요가 없음. 

이 정보는 기본 프로필로 묶어주면 되니, 따로 다룰 필요는 없을거고요.

 

 

 

필수정보 : 날짜
-  수업이 몇 월, 몇 일에 진행되는지. 당일 / 기간정보를 표현하기 위한 필수정보.

날짜정보는 월 단위로 묶을지. 일 단위로 묶을지를 좀 고민이 필요할거 같군요. 월 단위로 묶으면 과연 보기가 편할까요? 일 단위로 일정만 쭉 보여주는게 사용하기는 더 편할것 같네요.

 

 

이벤트 타입 
-  수강신청 시작 / 종료처럼. 시작과 끝이 연결된 타입은 하나의 정보로 묶어줘야함
단순 수업인지, 시험인지 구분도 필요함
-  수업이라면 온라인 강의인지, 오프라인 강의인지도 구분이 필요함
-  수업이든, 시험이든 오프라인 출석이 필요한지 여부는 별도확인 필요
-  오프라인 출석이라면, 관련 위치가 어디인지 알려줘야함

이벤트 타입이 가장 복잡합니다. 변수가 많거든요. 이걸 필터링으로 처리해야할지, 아니면 카드 내부에서 표현해야할지. 표현한다면 어디까지 표현해줄지를 고민해봐야합니다.

 

 

추가정보 : 기간 / 전공 및 교양 구분 
-  기간 타입 이벤트와, 당일 이벤트 구분이 필요함
-  전공 및 교양수업 구분의 경우, 정보 우선순위가 떨어지는 편

실제 카드에서 기간 / 당일 이벤트를 어떻게 표현해야할지 고민이 필요합니다. 전공 및 교양수업 정보를 표현할지. 표현한다면 어떻게 해야할지도 확인해야하고요. 

 

 

4. 해결방법 찾기 : 정보를 UI 단위로 옮겨보기

위에서 정리한 정보들을 기반으로. 전체 정보가 모두 들어갈 수 있는 공통 UI 카드를 만들어봤습니다. 여기서 중요한건 '이야기를 하듯이' 정보의 맥락이 읽혀야한다는 겁니다. 이 사람은 누구인데, 언제, 어떤 수업을 들어야한다는 식으로. 정보가 자연스럽게 읽혀야하죠.

 

주어진 정보만 갖고도 여러 타입의 정보를 구분할 수 있어야합니다.

 

 

저는 일정 타입을 크게 두가지로 봤습니다. 

-  단일 기간 타입과, A to B 기간별 타입
-  수업을 위한 정보 타입과, 학교 일정에 가까운 타입

 

두 정보를 하나의 UI 뷰 안에 넣어야하니, 비슷해보이는 규격이면 좋겠죠?

 

UI 설계는 항상 실험에 가까운과정이 많이 필요합니다. 정보를 묶어보고, 배치해보면서 가능하면 단순하게 만들어야하죠. 그래서 일단 '한가지 틀'로 묶어보고, 그게 불가능하다면 정보를 분리할 방법을 찾으면 됩니다. 다만 이 과정에서 빠진 정보가 UI 단위를 변화시킬 정도로 중요하다면. 이 모든 과정을 처음부터 다시 진행해야할 수도 있습니다. 그러니 가능하면 빠진 정보가 없도록 체크를 해봐야합니다.

 

 

실제로 컴포넌트를 와이어프레임으로 표현해본 화면

 

실제 UI 단위로 표현을 해보고 나니. 기존에 준비했던 타임라인 뷰의 카드 UI에 문제가 있다는걸 알게됐습니다. 분류를 위한 chip UI가 제목 상단에 있으니. 날짜와 수업명을 바로 확인하기 어려웠기 떄문이죠. 그래서 제목을 위로 올리고, 분류 chip들을 하단에 내리니, 훨씬 보기는 편해졌군요. 하지만 이렇게하니 이 카드가 '일반 강의'인지 '시험'인지. 해당 수업의 어떤 분류인지가 한 눈에 들어오질 않더군요. 게다가 기존에 생각했던 것처럼. 수업일정과 공지성 정보가 서로 구분되지 않는 문제도 있었습니다.

-  모든 분류를 굳이 chip UI로만 처리해야할까...?
-  타이틀에서 눈에 확 띠게 구분을 해주면 되지않을까?

 

 

중요한 이벤트의 경우, 타이틀에 직접 내용을 표현해주는 방식으로 문제해결 ! 

 

수업 타입의 chip UI에는 교수 이름과, 과 분류, 전공여부와 학년구분을 넣어줬습니다. 중요한 시험의 경우 타이틀에 따로 표기를 해주니 훨씬 보기가 편하더군요. 

 

공지성 정보는 기간이 있는 경우가 많으니, 시작과 종료를 따로 구분했습니다

 

공지성 정보의 경우기간이 있는 경우가 많으니. 타임라인 뷰에서 표현할때는 두 장을 쓰자고 생각했습니다. 그래야 시작과 종료 시점을 보기도 쉽고. 일반 수업 일정과 확연하게 구분이 될 테니까요. 이번 케이스에서는 두개의 카드를 한 곳에 담을 수 있었지만. 상황에 따라서는 UI를 새로 만들어야하는 경우도 생깁니다. 그래서 항상 일단 공통적인 부분을 묶어보고, 아니다 싶으면 바로 풀어서 다른 방법을 찾아야하죠.

 

 

최종적으로 만들어진 컴포넌트의 와이어프레임입니다.

 

마지막으로, 필터링 구분값을 상단에 추가해주니. 필요한 정보를 한눈에 볼 수 있는 타임라인 뷰 컴포넌트가 만들어졌습니다. 실제 기확과정이라면 전체 화면을 모두 포함해야하지만. 이번 과정은 이 컴포넌트를 정리하는 것으로 마무리를 하도록 하겠습니다. 

 


 

정리하는 글

모든 정보 구조에는 각자 고유한 이유가 있습니다

 

실제 실무에서는 다양한 정보를 정리하고. 다시 UI 단위로 묶는 여러가지 실험들이 필요합니다. 그리고 그 과정은 색상과 비례가 들어가기보다, 일단 '정보단위를 묶고, 모든 가능성을 이해하는' 것이 더 중요하죠. 완전하게 새로운 것을 만들어내는게 아니라. 주어진 정보를 어떻게 묶어줘야 이해하기가 쉬운지. 더 중요한 정보와, 상대적으로 중요하지않은 정보는 무엇인지. 그 순서를 정하는 과정이라고 할 수 있습니다. 

 

사실 실무에서 다루는 화면들은 이 케이스보다 훨씬 복잡한 경우가 많습니다. 관리자 화면같은 경우 묶어줘야할 정보가 수십개가 넘거나. 테이블 뷰가 너무 많아서 정보의 연결관계를 알기 어려워지는 경우도 많죠. 그런 케이스에서도 항상 생각해야하는건 이 두가지입니다. 

-  사용자가 그 페이지에서 어떤 판단을 내려야하는가.
-  그 판단을 위해 어떤 정보들이 필요한가.

 

 

UI 설계는 특히 논리와 정보의 맥락이 중요합니다. 그런 맥락을 풀어서 이야기하듯이. 누군가에게 설명해보거나, 글로 풀어서 정리해보면, 이런 논리를 파악하기 쉬워지죠. 시각적으로 아름다운 화면을 위해서가 아니라. 실제로 보고 사용하는 사람이 편리하기 위한 서비스를 만들려면. 항상 어떤 정보가, 왜 필요한지. 그게 실제로 정말 필요한지를 꼭 검증해보는 습관을 가지면 좋습니다.

 

오늘의 내용은 여기까지입니다. 다음에도 기회가 된다면, 보다 복잡한 정보가 담긴 화면을 기반으로. 설계 개선 작업을 진행해보겠습니다. 이해가 어려우시다면 어떤 지점이 어려웠는지. 댓글이나 의견을 주시면 추후 내용에 반영해보도록 하겠습니다. 긴 내용 읽으시느라 수고 많으셨습니다.

 


 

 

리플러스의 UD LAB에 대해 더 궁금하시다면, 다음 링크를 확인해보세요!

 

udlab.tistory.com/2

 

UD LAB - 이용안내

안녕하세요, 리플러스입니다. UD LAB (구 UI 디자인 연구소)은 UI 디자인과, IT 생태계를 집중적으로 다루고있는 커뮤니티입니다. 크게 단톡방과 디스코드 채널로 이루어져있으며, 주기적으로 디스

udlab.tistory.com

 

728x90

댓글