하지 말아야 되나? – 사용자한테 사용자 경험을 묻는다…?

…..리치 클라이언트 프로그램 개발은 두 종류가 있다. 아예 처음부터 새로 개발하는 경우와 기존의 프로그램을 아예 새로운 버전으로 업그레이드 하는 경우다. 대부분은 후자의 경우가 많다. 전자는 정말 설계가 튼튼해야 한다. 그래서 어느 정도 정형화된 형태에서 수정하는 형태로 사용자 경험을 만들어내는 경우가 많다보니 후자에 가까운 케이스로 되는 경우도 많이 존재한다.

뭐, 어떠한 형태가 되었던 간에 기존 시스템을 바탕으로 구현해야 할 의견을 찾게 된다. 이때에 사용자에게 기존 시스템에서 사용하기 어려웠던 점을 묻는 경우가 많은데, 내가 보기에는 물어서는 안된다고 본다. 이런 경우에는 대부분 부분적인 개선에 대해서 하나 하나 이야기를 하게 되는데, 사실 이런 경우에는 근본적인 해결이 아니라 그냥 자잘한 노가다 혹은 그만도 못한 작업을 해서 개선이 되는 요소가 존재하지 않게 된다.

예를 들어서, 여러 단계로 작성되는 웹 폼 화면을 개발하는데, 사용자에게 어려운 점을 물었더니 “2단계에서 물어보는 입력에 마지막 단계는 해당하지 않는데 이걸 그냥 놔둬야 하는지, 필수 입력인지 혼란스럽다.” 라고 해보자. 이런 경우에는 그냥 이 입력은 필수가 아닙니다 하는 형태로 설명을 달아주고 하는 형태로도 수정을 할 수 있다. 그러나 이런 식의 해결이 과연 근본적인 해결이었을까? 과연 이 마지막 입력이 정말 필요한 입력인지 아닌지를 묻고 필요한 입력이면 이전 단계의 값을 확인하여 동적으로 입력 폼을 보여주는 것이 더 좋은 해결책이 될 수 있는 거 아닐까? 표시되지 않는다면 사실 입력할 필요 자체가 없는 것이 된다.

하지만 이 일련의 과정을 사용자가 대답한다고 해서 좋은 해결책이 나올 수 있었을까?

사용자의 작업이 어느 화면에 어느 조작에서 막히거나 문제가 되는지를 알아내기 위해서 사용자가 사용하는 것을 캡쳐하거나 영상으로 찍어두고 분석하면 이런 해결책에 대한 해결 방법 중 하나가 되기도 한다. (고객센터에서 계속 원격으로 확인하면서 하는 게 이런 작업임…) 이런 식으로 사용자가 어떤 조작을 진행하였고, 어떤 조작을 요구하는지를 생각하면서 업무 순서와 내용을 분석한다. 그러면 부분적인 분석이 아닌 전체적인 분석을 하고 생각하면서 최선의 해결책을 찾는 것으로 이어지게 된다.

그리고 이런 건 사용자에게 물어서 확인할 수 있는 영역이 아니다. 사용자는 사용하다가 그냥 불편한 것에 대해서만 제공할 뿐, 이런 내용에 대해서 깊게 생각할 기회나 경험 자체가 없다. 리치 클라이언트에서의 사용자 경험에 우러난 조작성은 일련의 흐름을 갖고 있다. 그렇기 때문에 전후의 화면 사이에서도 깊은 의미를 가지고 있다. 이런 걸 특정 화면, 특정 기능에만 주목해서 보게 되는 사용자의 시점에서는 일련의 전체적인 흐름에 대해 보지 못해서 프로그램 개선을 망치게 될 수 있다.

그리고 이건 사실 사용자 뿐 아니라 영업 관점에서도 여러모로 말 나오는 이야기일 수 있다. 영업 입장에서는 사용자쪽을 이해 혹은 설득하는 듯한 작업 수순을 통해서 설명하고 그에 따른 이야기들을 듣고 오다보니 사용자쪽 시선에 갖춰져서 시선이 좁아지는 경우도 생기기 마련이기 때문에다. 그래서 영업과 개발이 싸우기도 하고…./먼산

하지 말아야 되나? – 사용자 경험을 무조건 다 집어넣을 수는 없다. 요건이 아니다.

오늘은 블로그 글을 여러모로 적으면서 볼일 보는 걸 기다리고 있다만… 리치 클라이언트 관련 이야기를 하다 보면 여러모로 하고 싶었던 이야기가 있었다. ;ㅅ; 그 중에서도 사용자 경험에 대해서도 여러모로 하고 싶은 말도 있다. 나도 과거에 실수했던 내용이기도 하고 해서..ㅠㅠ

리치 클라이언트가 주목받는 가장 큰 이유는 보다 나은 사용자 경험을 표현하여 개발할 수 있다는 것이다. 사용자 경험에 대한 부가 설명을 간단하게 하면 인지 심리학자 도널드 A 노먼씨가 미국 애플에서 UI를개발하고 있었을 때 만든 개념으로, 이를 통해 다른회사의 제품과 차별을 두기 위해 생각한 개념인데 이게 널리 퍼졌다.

이 개념에 중심에 있어서 외관을 먼저 디자인 하는 것이 아니라 사용자 시점에서 사용하기 쉽게 한다는 점에 목적을 두고 설계를 하는 사용자 중심의 설계를 기반으로 하고 있다.

리치 클라이언트에서는 지금까지 본 적도 느껴본 적도 없는 조작 위주의 UI를경험할 수 있다. 그러나 이것을 구현하기 위해서는 사용자에게 어떤 서비스를 어떻게 제공해 주어야 감동을 줄 수 있는지에 대해 충분히 검토한 후에 디자인 해야 하는 것이 중요하다. 이러한 디자인을 사용자 경험 디자인이라고 하며, 사용자의 분석, 컨셉의 명확화, 테스크 분석, 실물 모형을 촬영한 동영상 제작, 프로토 타입 제작, 목표 명확화 등 여러 스텝을 밟고 해야 한다. 자세한 건 UX관련 서적들이 자세히 써놓았다.

근데 이러한 작업들은 노력도 시간도 많이 들기 때문에 기본적으로 비용 증가로 연결된다. 그래서 승산 없이 사용자 경험을 마구잡이로 포함시켜서는 안된다.

오히려 사용자 경험에 대한 건 기능적 요건이 아니라 부가가치적 개념으로 들어가야 한다.

사용자 경험은 리치 클라이언트에서 반드시 필수인 것은 아니다. 즉, 기능 요건이 아니라 부가 가치인 것이다. (이걸 헷갈리면 진짜 프로그램 개발 산으로 간다)

응용 프로그램에서 사용자 경험을 적용하면 사용자의 지원 및 비용을 줄일 수 있거나 조작 오류를 감소시킬 가능성이 높다. 경우에 따라서는 몇 번 사용해 보고 기분 좋은 경험을 고객에게 전달해 줌으로써 제품을 계속 사용하게 만들는 효과를 가져올 수 있다. (애플은 이걸 정말 잘 아는 기업이다. 그리고 요즘의 마이크로소프트도 이에 대한 도전을 많이 하고 있다.) 이러한 부가 가치의 금액을 정확하게 산출하는 것은 일반적으로는 어려운 일이다. 그러나 가능한 한 금액으로 환산하여 사용자 경험을 구축하는 데 드는 비용과 비교하여 도입 유무를 잘 검토하는 것이 중요하다.

그리고 이 글 작성하면서 도중에 적었다만, 이걸 정말 잘 하는 기업이 애플이라고 했다. 그리고 앱스토어에 있는 수많은 앱들 중 에디터의 초이스로 선택된 앱들 또한 그런 것들을 가지고 있다. (애플 디자인 어워드에 있는 앱들 또한 마찬가지..) 그 앱들 중에서는 비슷한 기능을 가지면서도 더 기능 많은 앱들이 앱스토어에 있는 거 같은데도 뽑힌 이유는 바로 그 앱들이 가지는 고유의 사용자 경험이 애플의 에디터들을 만족시킨 것이다. 그래서 앱 개발에 있어서 여러모로 난이도가 올라간 것들이 없지 않게 존재한다.

하지 말아야 되나? – 화면 디자인이나 화면 이동, 변경에 대해서 이게 최선이다라고 생각하고 하면 안된다.

지금은 되게 당연하게 받아들이게 된 이론인 MVC, MVVM 같은 녀석들을 왜 이용하는지에 대해서는 솔직히 이런 걸 먼저 가르치면서 해야 한다고 생각은 하는데… 사실 이런 내용은 현업에서 하다보면 나중에 되어서야 알게 되는 참 힘든 내용인 듯 하다.

개발 초기 단계에서 회의 끝에 초기의 UI 모양이나 조작에 대한 사양은 정해진 거 같으면서도 정해져 있지 않다고 보면 된다. (즉, 나중에 미친 듯 갈릴 수 있다는 것이다.) 그래서 리치 클라이언트 응용 프로그램의 경우에는 어플리케이션 설계 시에 계층 구조를 가지고 개발을 하는 것이 좋다. 전통적으로 보는 계층 구조는 다음과 같은 것들이 있다.

  • 자산: 주로 이미지 소재 같은 가공된 내용물들임.
  • 상호작용: 이벤트 등에 대한 시스템이 반응하는 녀석
  • 컨트롤, 레이아웃: 그래픽 컨트롤들과 그를 배치한 레이아웃
  • 이벤트: 사용자 인터페이스에 대한 조작 관련 이벤트들
  • 비즈니스 로직: 응용 프로그램이 처리할 처리 내용이나 그에 대한 기준 데이터들

이런 것들을 우리는 어디서 비슷한 녀석을 본 거 같다. 바로 이 글의 맨 앞에서 이야기 한 응용 프로그램 개발할 때 프로그램 구조에서 이야기하는 디자인 패턴들, MVC, MVVM 같은 녀석들 설명 듣고 할 때 많이 본 것들이다. 리치 클라이언트에서는 뷰에 대한 요구와 수정이 주로 일어나기 때문에 뷰에 대한 것과 뷰를 구성하고 실행하는 것에 대해서 분리하여 처리하는 여러 과정들 중 일부들… 바로 이런 것들 땜에 나오는 이야기인 거다.

여기서는 좀 전통적인 로직에 맞춰서 설명을 하겠다. (규링은 이런 내용에 기반한 걸 먼저 배운 관계로…ㅠㅠ) 최하층의 비즈니스 로직과 이벤트는 사실 개발 도중에 변경 사항이 나오기 상당히 드문 것들이다. 이게 바뀐다는 건 사용하는 데 있어서 필요한 비즈니스 로직 자체가 바뀌었다는 내용이 되기 때문이다. 그리고 이것들은 중간에 있는 컨트롤, 레이아웃에 의해 호출되어 결과만 제대로 나와주면 되기 때문에 컨트롤과 레이아웃에 대해서는 어느 정도의 사양만 제대로 갖춰지기만 해도 충분히 맞춰 개발할 수 있다.

문제는 상위에 있는 자산, 상호작용 부분들인데, 이 부분들에 대해서는 할 말이 없다….;ㅅ; 사실 끝의 끝까지 가서도 바뀔 수 있는 녀석들이다. 그래서 이 영역의 코드들은 마지막의 마지막까지 그냥 “튜닝한다” 라는 내겸을 가지고 가야 한다. 그래서 코드 분리의 개념이 엄청나게 잘 되어있고 그걸 당연한 듯이 설명하고 그걸 잘 이용하기 위한 프레임워크들을 이용하는 것이지만….ㅇㅂㅇ;;;;

하지 말아야 되나? – 어플리케이션의 리치화, 함부로 하면 안된다. 잘 계획해서 해야 한다.

전글에서 리치 클라이언트에 대한 이야기를 하면서 리치화에 대한 이야기를 간단하게 했다. 그러면서 디자이너 이야기를 적었는데….

리치화는 바로 디자인과 사용자 경험에 대한 결합을 통해 어플리케이션을 더욱 돋보이게(제일 비슷한 뜻일듯..) 하는 작업이라고 보면 된다. 나도 이걸 어디 책에서 본 내용 기반으로 설명하려 하니 어려운데… 흔히 말하는 디자인, 사용자 편의성따위 없는, 누가 봐도 개발자가 자기 생각만 하고 짠 듯한 그런 응용 프로그램 보면 이게 뭐야? 하는 게 리치화가 안된 프로그램이다.

리치 클라이언트 응용 프로그램 개발에는 많은 비용과 시간이 들어간다. 나의 천적 오씨가 화면만 3년 걸려(노는 시간 합쳐서) 화면만 만들고 튄 것도 좋게 보면 프로그램을 리치화 시켰다고 할 수 있다. (그렇다고 그양반이 잘했다는 거 아니다.)

또 이걸 이용하는 기술에 따라서는 읽기나 별도의 렌더링 처리에도 시간과 자원이 들어가는 일이 발생한다. 그렇게 해서 런타임 환경과 버전 관리하고 하는 운용 관련 시간도 추가로 들어가게 된다. 그래서, 리치 클라이언트는 사실 만들었다고 해서 사용이 쉽거나 관리가 쉽거나 하는 게 아니다. 여기에 특히 기존 어플리케이션에 대해서 리치 클라이언트화를 검토할 때에는 사용자의 사용 환경(PC 사양)이나 기존 응용 프로그램의 익숙도를 충분히 고려한 작업을 해야 한다.

규링의 간접 경험을 예로 들면, 건강 정보 관리하는 어플리케이션을 만들 때 좀 더 리치 클라이언트화하여서 입력 기능을 좀 더 상향화(라고 할 수 없긴 했다만…)하고 싶다는 이야기를 받았따. 기존 화면은 그냥 기본 제공되는 UI 프레임워크에 이미지와 약간의 애니메이션만 넣어서 프로토타입화 하고 있던 녀석인데, 이걸 입력하는 화면하고 보여주는 화면하고의 느낌을 안드로이드 화면과 비슷하게 만들라는 것이었다. 당시 난 걍 iOS 4 버전대에 그 회사에서 안드로이드로 이미 개발되어 있던 녀석을 아이폰에서 똑같은 화면과 기능으로 개발을 하는 녀석이었는데… 화면 뒤로가는 버튼 없는 것부터 시작해서 여러모로노 안드로이드만 생각하고 만들어진 녀석을 아이폰 사용자가 그나마 덜 이상하게 생각할 수 있도록 하는 거였다만.. 안드로이드 개발자한테 가서 이상한 기능을 더 추가하고 하는 바람에 쓸데없는 부하가 걸리고 했다. 게다가 몇몇 기능은 아이폰 3GS 화면에서 처리하기 좀 무리가 가는 녀석도 있었다.

그래서 프로그램 이용에는 방해가 되고, 난 시간이란 시간 다 빼먹고, 이걸 나름 잘 해보겠다고 해서 리치화 시킨 아이디어였지만 결국은 업무를 방해한 녀석이 되었다. 그래서 안드로이드 개발하던 선배와 이야기 한 결과, 특정 화면만 좀 더 디자인 더 넣고 해서 리치해 보이게 만드는 그런 작업을 했었다…

이런 거 잘못 생각하면 진짜 쓸모없는 쓰레기 만들기 딱 좋은 환경 된다. ㅠㅠ

하지 말아야 되나? – 리치 클라이언트를 개발할 때, 실물 모형과 프로토타입을 혼동하면 안된다.

하지 말아야 되나 시리즈를 작성하다 보면 여러모로 용어들이 막 튀어나올 것인데, 그 중에서는 진짜로 이런 용어가 있어? 하는 듯한 것이나 버즈워드(여러곳에서 막 이용되는 용어)에 대해서 혼동하는 경우를 많이 보게 될 것이다. 지금 것도 그 중 하나라고 보면 된다.

리치 클라이언트라는 것은 사용자가 헤메지 않고 조작할 수 있는 것은 물론이면서 인터페이스 측면에서도 사용하기 좋은 클라이언트를 가리켜서 말하는 용어이다. 여기서 말하는 리치화에 대해서는 이 다음에 별도로 설명할 시간이 있을 것이다.

근데 이 리치 클라이언트 형태의 응용 프로그램을 개발할 때에는 사용자의 경험을 살려 동작하도록 하는 것을 일반적으로 보게 된다. 근데 최적의 조작을 생각하다 보면, 지금까지 해본 적 없는 사용자 조작을 만들어야 하고, 이를 위해 디자이너와 사용자(실제 사용자, 혹은 발주를 넣은 고객사 사람. 발주 내용을 확인하고 최종 승인하는 대상이 될 것이다.)와의 인식을 맞춰야 한다. 이때, 디자이너는 일회용을 전제로, 단시간에 작성하여 자신이 만든 이미지를 상태에게 전달하여 실물 모형을 만들어 쓰기도 한다. 그러나 한편으로는 프로토타입은 실물 모형(모델)을 기반으로 사용하여 확장시킨 UI를 컨셉으로 구현한 것을 이용한다. 그러다보면 실제 사양에 대한 확장 개념으로 이용할 뿐, 그래픽이나 조작 방법에 대해서는 많은 노력과 시간을 들여서 계속 수정해 나가야 한다.

이러한 경우, 양쪽의 차이를 이해 안하고는 그냥 검도 단계로 들어가게 되면 그대로 싸우게 된다. 검토하는 과정에 이르러서야 어느 정도 서로간의 관점차이가 보이기 시작한다. 이때 잘 해결해서 실물 모델에 의한 프로토타입의 이해를 디자이너에게 의뢰해서 처리할 경우에는 이러한 실패가 덜 들어갈 수 있으나, 그냥 프로토타입을 요구하게 되면 뜬금없는 수준의 디자인을 받게 되고, 이는 비용에 대한 낭비로 이어지게 된다.

글이 어려운데… 간단히 말하면 디자이너에게도 어느 정도의 프로토타입과 실물 모델에 대한 이해를 시켜야 한다는 뜻이다.

…..아 근데 언제부터 이런 내용 생각할 때 딱딱한 내용부터 적기 시작한 거지….ㅠㅠ