[디자인 서적 추천 02] 객체지향 UI 디자인
일상에서 앱을 사용하다 편하다 혹은 불편하다는 생각이 든 적이 있을 겁니다. 하지만 누군가 왜 그렇게 생각했냐고 묻는다면 명확하게 답하기 어려울 수 있습니다.
그렇다면 이렇게 긍정적인 혹은 부정적인 경험을 하게 하는 제품의 공통점은 무엇일까요? 그리고 그 단서가 될 수 있는 책을 소개합니다.
사실 이 책은 소프트웨어 개발에서 주로 언급되는 객체지향 개념을 다룬 책으로, 디자이너가 접했을 때 다소 이해가 어려운 부분도 있습니다. 제가 이해한 대로 내용을 정리해 봤는데, 디자이너 시점에서 쓴 내용이라 다소 틀린 부분이 있을 수 있습니다. (*피드백은 언제나 환영)
객체지향 UI(Object-Oriented UI)
객체지향 UI는 사용자가 UI를 태스크 중심이 아닌 오브젝트 즉, 사용자의 목적 중심으로 이해하고 조작하도록 설계된 UI를 의미합니다. 여기서 오브젝트란 애플리케이션이 취급하는 정보 오브젝트를 뜻하는데, UI를 구성할 때 이 오브젝트를 단서로 화면과 데이터가 대응되도록 만든 방법론이 객체지향 UI 설계라고 합니다.
객체지향의 반대가 되는 태스크지향과 비교를 하면 좀 더 이해가 쉬워집니다.
책에서는 태스크지향의 문제점을 지적하며 객체지향 설계법을 제안합니다. 태스크지향의 경우 사용자가 태스크를 선택하면 UI가 특정 모드에 들어가고, 이 모드를 벗어나기 전가지 다른 작업을 수행할 수 없습니다. 즉, 사용자의 자유도를 제한하고 다른 작업을 하기 위해 불필요한 과정이 늘어납니다.
위 표의 예시를 들면 이메일 삭제 버튼을 클릭해 삭제 모드에 들어간 경우 삭제를 완료하거나 취소와 같은 버튼을 눌러 삭제 모드에서 빠져나간 후에야 회신, 이동과 같은 다른 작업을 수행할 수 있다는 것입니다.
반면 객체지향의 경우 이메일이라고 하는 오브젝트를 선택한 후 할 일(태스크)을 고르기 때문에 특정 모드에 갇히지 않고(모달리스) 여러 작업을 동시에 수행할 수 있습니다.
이런 방식은 현실세계의 흐름과 유사해 쉽게 이해할 수 있습니다. 현실세계에서도 우리는 물건을 살 때 물건(오브젝트)을 먼저 고르고, 값을 지불(태스크)합니다. 만약 태스크 지향으로 현실세계를 바꿔본다면 값을 먼저 지불한 후에 물건을 선택하고, 구매를 하지 않거나 지불한 값과 선택한 물건 사이에 가격 차이가 있다면 또 다른 불필요한 과정이 발생할 것입니다.
객체지향 UI 설계의 또 다른 장점은 확장성을 보장해 효율적인 UI설계가 가능하다는 것입니다.
예를 들어 사용자가 특정 기능을 요청할 때 태스크별로 각각 디자인하는 것이 아니라, 각 태스크 안에 있는 공통 요소, 즉 오브젝트를 찾아 태스크들을 관철하도록 설계하는 것을 목표로 합니다.
예를 들어 이메일 애플리케이션에서 이메일을 아카이브 하는 기능이 추가된다고 가정해 보겠습니다.
태스크지향 UI에서는 "아카이브 모드"를 새롭게 설계해야 하고, 기존의 삭제, 이동, 회신과는 별도로 새로운 UI를 만들어야 할 수도 있습니다. 하지만 객체지향 UI에서는 이미 "이메일"이라는 오브젝트가 존재하기 때문에 이 오브젝트가 수행할 수 있는 기능으로 "아카이브"를 추가하기만 하면 됩니다. 이렇게 공통 오브젝트를 기반으로 기능을 확장할 수 있기 때문에 불필요한 화면 추가를 줄이면서 확장성을 유지할 수 있습니다.
그렇다면 이러한 객체지향 UI 개념을 디자인할 때 어떻게 적용할 수 있을까요?
저의 경우 이 책에 크게 감명받아 프로젝트 진행 전 팀원들(개발자, 기획자)과 함께 도메인 다이어그램을 작성하는 단계를 제안했습니다. 우리 조직의 경우 3주 스프린트 단위로 프로젝트를 진행하기에 프로젝트를 작은 단위로 쪼개 진행하는데요. 그러다 보면 전체 흐름에 대한 구성원 간 생각의 불일치가 생길 때도 있는데, 이 단계를 추가하니 제품의 큰 흐름에 대한 이해도가 높아지고, 효율적인 진행이 가능했습니다.
*도메인 다이어그램(Domain Diagram) : 비즈니스 개념과 객체 간의 관계를 나타내는 다이어그램
Excalidraw라는 툴을 이용했는데, 위 사진과 같이 제품에서 주요한 객체(오브젝트)와 객체가 담아야 하는 데이터(속성), 객체가 수행할 액션(메서드)을 정의하고 각 객체 간 관계를 정의했습니다.
도메인 다이어그램을 작성함으로써 제가 느낀 장점을 좀 더 나열하자면 아래와 같습니다.
1. 팀 내 오브젝트 용어와 개념을 통일해 커뮤니케이션이 원활해짐
2. 디자인, 개발 설계가 일관되어 추후 수정 비용 절감
3. 주요 액션에 집중한 화면 설계 가능
4. 전체 흐름을 이해하고 UI의 재사용 가능성을 염두한 화면 설계 가능
책을 읽고 업무에 적용하는 과정을 통해 디자이너, 즉 직역 시 설계자인 나의 역할을 좀 더 이해하게 되었다고 생각합니다. 입사 초기엔 내가 예상하지 못한 케이스가 개발 중 등장할 때 내 역량에 대한 회의감을 느끼며 자책하곤 했는데, 요구된 태스크에만 집중한 태스크 지향 설계를 했다는 회고도 할 수 있었습니다.
끝으로 책에서 인상 깊었던 문장과 함께 추천하며 마무리합니다.
객체지향 UI는 단순히 내비게이션 레벨을 '명사'로 하거나 조작 순서를 '대상 선택 → 액션 선택'으로 하는 표현상의 스타일을 말하는 것이 아니라. 사용자 앞에 대상의 이념을 솔직하게 표현하는 것이다. 사용자에게 절차를 지시하는 것이 아니라, 목적 그 자체를 제시하는 태도다. 그리고 우리는 그 제시가 이윽고 사용자의 환경과 행동을 바꾸고 새로운 의미로 자라날 것을 상상한다. (중략) 그렇게 사람들에게 목적을 되돌려주는 것이 객체지향 사용자 인터페이스 디자인이다.