들어가기 전에.
우연히 교보문고에서 보았는데 제목부터 흥미로워서 도서대장으로 구매했는데, 내용이 좋아서 이번 위클리에서 공유하려고 합니다. 디자이너에게 친숙하지 않은 ‘객체 지향’ 이라는 단어에 겁 먹을 수 있는데, 책의 내용은 워크북에 조금 더 가까워서 이해가 잘 되는 편입니다.
이번 프리젠테이션에서는 객체 지향 UI 디자인의 개념과 간단한(아마도?) 프로세스만 공유할 예정입니다. 이후에 기회가 되면 모달과 모달리스, 모달리스 신봉하기 라는 내용도 공유해보겠습니다.
(모든 형태에 서비스, UI에 객체 지향 UI를 바탕으로 설계 해야 한다는 것은 아닙니다. 중요한 점은 각각 서비스, 구조에 맞는 방법론이 있으며, 그 방법론을 올바르게 이해하고 잘 적용하는게 중요합니다.)
(무언가 구질구질 하지만.. 부연하면 굳이 방법론이 필요 없는 경우도 있습니다..)
객체 지향 프로그래밍
객체 지향 프로그래밍이란?
객체 지향 프로그래밍은 컴퓨터 프로그램 을 명령어 의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 “객체“들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.
참고) https://ko.wikipedia.org/wiki/객체지향프로그래밍
객체 지향 UI 디자인은 이름에서 알 수 있듯이 객체 지향 프로그래밍에서 나온 개념입니다. 객체 지향 프로그래밍은 일종의 개발 패러다임으로 흥미롭게도 GUI가 등장하면서 급부상한 개념입니다. 이전에는 절차적 프로그래밍이 주류를 이루었는데, 절차적 프로그래밍이란 쉽게 이야기 하면 명령어를 바탕으로 하는 프로그래밍입니다. (ex 터미널, 커멘드 라인)
GUI가 등장하고 복잡한 화면과 여러개의 창이 함께 동작하게 되면서, 한 개의 명령어를 보내더라도 각 창에서 다른 결과를 보여줘야 했고 서로 상호작용이 가능해야 했습니다. (이런 복잡한 동작은 절차적 프로그래밍으로는 해결하기 매우 어렵습니다. 마치 급여정산을 ‘예/아니오’ 로 해야하는..)
절차적 프로그래밍의 한계를 넘기 위해서 구조적인 대안으로 독립적인 작은 단위의 객체(Object)를 만들고 객체들을 조합하고 재사용해서 큰 문제를 해결하는 방식이 객체 지향 프로그래밍 입니다.
객체 지향 UI란?
UI에서 객체
객체 또는 오브젝트라고 표현하겠습니다. UI에서 객체를 가장 잘 설명할 수 있는 것은 파일 아이콘 입니다. 우리는 파일 아이콘을 통해서 파일의 위치를 옯길 수 있고, 복사, 편집, 압축 또는 삭제까지 할 수 있습니다. 객체란 사용자가 보았을 때, 실제로 존재하는 무언가 처럼 물리적인 경험을 주는 ‘물체’를 의미합니다.
조금 더 추상적인 객체를 설명하면, 우리가 받아보는 ‘이메일’을 예시로 들어볼 수 있습니다. 이메일은 실제로 물리세계에 존재하지는 않지만 우리는 관념적으로 GUI 안 에서 이메일 리스트에서 메일을 확인하고, 중요 표시를 하고 삭제하거나 메일함을 옮길 수 있습니다.
따라서 간단히 축약해서 객체 = 물체 라는 관점으로 접근을 하면 UI 안에서 객체에 대한 이해가 조금 더 쉽습니다. 그리고 객체 지향 UI 안에서 객체는 보통 ‘목적’ ‘명사’를 기반으로 정의됩니다.
객체와 테스크
파일과 메일을 통해서 객체의 개념을 알아보았는데 이런 객체를 ‘지향하는 UI’란 무엇인가에 대해서 알아볼 차례입니다. 객체를 지향하기 위해서는 객체를 움직이고, 상태를 변하게 만들고, 삭제 할 수 있도록 하는 ‘테스크(액션)’가 반드시 필요합니다.
테스크는 보통 ‘동사(명령어)’로 지칭되면서 오브젝트의 액션을 관장합니다. 동사(명령어)를 바탕으로 하는 것은 ‘절차적 프로그래밍’과 상통한다고 할 수 있습니다. 그래서 절차적 프로그래밍과 동일한 한계를 갖고 있습니다. 테스크를 우선 지향하는 UI 체계는 사용자에게 액션을 우선 선택하게 하고 이후에 액션이 적용되는 오브젝트를 선택하게 만들기 때문에 사용자의 두려움을 유발할 수 있습니다. (사용자는 액션을 선택하기 전까지는 본인이 어떤 오브젝트에 액션을 적용하게 될지 알 수 없습니다.)
객체 지향 UI
따라서 객체 지향 UI는 ‘물체’를 선택하고 ‘물체’에 대한 ‘액션’을 선택하는 구조로 이루어져있습니다. 객체를 우선으로 하는 구조는 사용자가 원하는 물체를 우선 선택하고 해당 물체에 대응하는 액션과 데이터를 받아서 상호작용하기 때문에 사용자의 이해가 쉽습니다. 또한 같은 성질의 객체 또는 서로 영향을 받는 객체를 바탕으로 다양한 화면을 구성할 수 있으며, 훨씬 적은 수의 화면으로도 다양한 테스크를 소화 할 수 있습니다.
(리스트, 컬렉션, 카드, 태그 등 보편적으로 사용하는 UI 패턴에 훨씬 더 쉽게 추상화 해서 적용할 수 있습니다.)
객체 지향 UI의 원칙
- 오브젝트를 지각할 수 있고 직접 조정할 수 있다.
- 오브젝트는 자신의 성질과 상태를 나타낸다. (선택, 호버, 로딩, 실패, 다운로드 등)
- 오브젝트 선택 → 액션 선택의 조작 절차를 바탕으로 한다.
- 모든 오브젝트는 서로 협조 또는 상호작용 할 수 있으며 이를 바탕으로 UI 화면을 구성한다.
객체 지향으로 UI 설계하기
애플리케이션 디자인의 프로세스
애플리케이션의 디자인 시작점은 보통 테스크를 바탕으로 ‘000을 할 수 있는 앱’ 또는 객체를 바탕으로 ‘ㅁㅁㅁ을 확인 할 수 있는 앱’으로 시작됩니다. 객체 지향 UI 설계에서는 어느 관점에서 시작하던 객체를 추출하여 시작하는 것을 기본으로 합니다.
애플리케이션의 UI는 사용자와 관심 대상(오브젝트)를 연결하는 일종의 공간입니다. 이러한 관심 대상은 의미 그대로 파일 처럼 실제 같은 대상을 의미하기도 하지만 이메일, 메시지 같은 추상적인 모델 개념을 의미할 수도 있습니다.
객체 지향 UI 디자인에서 3가지 레이어로 UX 플로우와 UI를 설계합니다.
- 모델 레이어
- 인터렉션 레이어
- 프리젠테이션 레이어
모델은 사용자의 관심 대상을 모형화한 것입니다. 모델 레이어에서는 앱의 설계 단서가 되는 현실 세계의 존재 방식 예를 들어 사용자의 특징, 업무 형태, 정보 서식, 요구 사항의 종류와 관계성 등을 기반으로 추상화된 모형을 제공합니다.
객체를 모형화 할 때는 타겟이 되는 도메인의 사용자 조사가 충분히 되어야 합니다. 만약 불충분하다면, 사용자의 행동 패턴, 사용 방식을 적절하게 반영한 모델을 만들 수 없게 되고 전체적인 방향성이 잘못될 수 있습니다.
인터렉션은 디자인의 기능에 대한 레이어로 모델링이 된 객체의 액션과 데이터 호출방식을 담당합니다. 탭, 클릭, 선택, 입력, 삭제 등 사용자가 객체에 기대하는 다양한 액션을 일관성 있는 문법으로 제공 합니다.
또한 모델링 된 객체에 데이터 호출 방식을 바탕으로 여러가지 뷰를 부여합니다. 예를 들어 ‘메시지’ 오브젝트에 메시지 아이콘, 메시지 리스트, 메시지 상세 내용, 알림, 메시지의 메타 데이터 등과 같은 정보를 정리하는 역할을 합니다.
*앞서 말한 테스크(액션)을 의미한다고 생각하면 이해가 조금 더 쉽습니다.
프리젠테이션은 디자인 레이어로 모델링이 된 객체와 상호작용하는 인터렉션을 바탕으로 구체적인 UI로 표현하는 역할을 담당합니다.
추상적인 오브젝트를 추출 예시 (모델링)
열심히.. 설명했지만 아마도 모델에 대한 개념을 이해하기 어려웠을 것 같습니다. 우리는 정말 매우 추상적인 ‘인사’를 다루기 때문에 추상적인 대상을 구체화하는 모델링이 매우 중요합니다.
오브젝트를 추출하기 위해서는 사용자가 도메인에서 무엇을 하는지, 어떤 업무(역할, 플로우, 필요로 하는 정보, 받거나 보내는 정보)를 하는지 파악해야 합니다. 이를 위해서는 흔히 말하는 ‘리서치’ 단계가 필요합니다.
오브젝트 추출 방식에 대한 예를 ‘이메일’ 도메인을 바탕으로 설명하겠습니다. 사용자들이 이메일 도메인에서 관심있는 테스크는 아래와 같습니다.
- 메시지를 받는다
- 메시지를 보낸다.
- 메시지를 임시 저장한다.
- 받은 메시지들을 확인한다.
- 중요 메시지들을 따로 저장한다.
- 보낸 메시지를 확인한다.
- 필요 없는 스팸 메시지들을 삭제한다.
- 프로모션 메시지들을 받는다. / 확인한다.
- 관심 소식 메시지들을 받는다 / 확인한다.
- 회사 동료들의 메시지를 받는다 / 확인한다.
- 친구들의 메시지를 받는다 / 확인한다.
오브젝트는 보통 명사를 지칭한다는 점을 보았을 때, 개별 명사를 추출해보면 아래와 같습니다.
- 받은 메시지
- 보낸 메시지
- 중요 메시지들
- 필요 없는 스팸 메시지
- 프로모션 메시지들
- 관심 소식 메시지들
- 회사 동료들 메시지
- 친구들 메시지
여기서 조금 더 그룹핑을 해서 추상화를 진행해서 오브젝트를 추출해보면 아래와 같습니다.
- 메시지
- 메시지들 (분류를 통해서 여러개의 메지시들을 갖고 있는 메일 박스로 치환할 수 있습니다.)
이렇게 추출된 오브젝트를 바탕으로 사전에 조사한 테스크와 함께 조합하면 메시지에 어떤 인터렉션이 요구되는지 파악하고 디자인을 진행할 수 있습니다.
- 액션 : 보내기, 받기, 삭제하기, 저장하기 등
- 데이터 : 언제 보냈는지, 언제 받았는지, 저장 유무 등
- 뷰 : 단일 메시지 뷰, 여러개의 메시지들을 확인 할 수 있는 뷰 등
오브젝트 판단하기
조금 극단적인 예시이기는 했지만 명사 추출과 그룹핑을 통한 추상화 단계를 경험해본 것 같습니다. 이를 통해서 알게된 추상적인 오브젝트를 판단할 수 있는 근거는 아래와 같다는 것을 알 수 있습니다.
- 명사로 이루어져있다. (셀 수 있다.)
- 같은 종류의 집합으로 관리할 수 있다. (메일 박스)
- 공통의 액션을 갖고 있다. (모든 메시지는 삭제, 중요 표시, 전송 등의 액션이 가능합니다.)
항상 프로세스를 따라서 디자인 해야할까?
디자인의 궁극적인 목적은 ‘뛰어난 형태를 갖추는 것’ 이기 때문에 좋은 UI를 디자인하기 위해서라면 당연히 그래픽 형태를 우선적으로 고려해야 합니다. 이런 관점이라면 그 아래에 있는 구조는 프레젠테이션 레이어와 모델, 인터렉션 레이어 사이의 논리가 어긋나지 않도록 하는 최소한의 장치에 지나지 않습니다.
그렇지만 구조적인 배경이 없이 뛰어난, 좋은 형태의 디자인만 추구하는 것은 사용자가 납득할 수 있는 논리적인 인터렉션과 화면을 표현하는데 한계를 반드시 만나게 됩니다.
따라서 뛰어난 형태를 지니면서도 논리적인 구조를 지닌 디자인을 위해서는 모델 레이어와 인터렉션 레이어, 프레젠테이션 레이어를 왔다 갔다 하면서 겪는 시행착오(디자인 이터레이션)를 바탕으로 디자인의 완성도를 높여야 합니다.
