…..리치 클라이언트 프로그램 개발은 두 종류가 있다. 아예 처음부터 새로 개발하는 경우와 기존의 프로그램을 아예 새로운 버전으로 업그레이드 하는 경우다. 대부분은 후자의 경우가 많다. 전자는 정말 설계가 튼튼해야 한다. 그래서 어느 정도 정형화된 형태에서 수정하는 형태로 사용자 경험을 만들어내는 경우가 많다보니 후자에 가까운 케이스로 되는 경우도 많이 존재한다.
뭐, 어떠한 형태가 되었던 간에 기존 시스템을 바탕으로 구현해야 할 의견을 찾게 된다. 이때에 사용자에게 기존 시스템에서 사용하기 어려웠던 점을 묻는 경우가 많은데, 내가 보기에는 물어서는 안된다고 본다. 이런 경우에는 대부분 부분적인 개선에 대해서 하나 하나 이야기를 하게 되는데, 사실 이런 경우에는 근본적인 해결이 아니라 그냥 자잘한 노가다 혹은 그만도 못한 작업을 해서 개선이 되는 요소가 존재하지 않게 된다.
예를 들어서, 여러 단계로 작성되는 웹 폼 화면을 개발하는데, 사용자에게 어려운 점을 물었더니 “2단계에서 물어보는 입력에 마지막 단계는 해당하지 않는데 이걸 그냥 놔둬야 하는지, 필수 입력인지 혼란스럽다.” 라고 해보자. 이런 경우에는 그냥 이 입력은 필수가 아닙니다 하는 형태로 설명을 달아주고 하는 형태로도 수정을 할 수 있다. 그러나 이런 식의 해결이 과연 근본적인 해결이었을까? 과연 이 마지막 입력이 정말 필요한 입력인지 아닌지를 묻고 필요한 입력이면 이전 단계의 값을 확인하여 동적으로 입력 폼을 보여주는 것이 더 좋은 해결책이 될 수 있는 거 아닐까? 표시되지 않는다면 사실 입력할 필요 자체가 없는 것이 된다.
하지만 이 일련의 과정을 사용자가 대답한다고 해서 좋은 해결책이 나올 수 있었을까?
사용자의 작업이 어느 화면에 어느 조작에서 막히거나 문제가 되는지를 알아내기 위해서 사용자가 사용하는 것을 캡쳐하거나 영상으로 찍어두고 분석하면 이런 해결책에 대한 해결 방법 중 하나가 되기도 한다. (고객센터에서 계속 원격으로 확인하면서 하는 게 이런 작업임…) 이런 식으로 사용자가 어떤 조작을 진행하였고, 어떤 조작을 요구하는지를 생각하면서 업무 순서와 내용을 분석한다. 그러면 부분적인 분석이 아닌 전체적인 분석을 하고 생각하면서 최선의 해결책을 찾는 것으로 이어지게 된다.
그리고 이런 건 사용자에게 물어서 확인할 수 있는 영역이 아니다. 사용자는 사용하다가 그냥 불편한 것에 대해서만 제공할 뿐, 이런 내용에 대해서 깊게 생각할 기회나 경험 자체가 없다. 리치 클라이언트에서의 사용자 경험에 우러난 조작성은 일련의 흐름을 갖고 있다. 그렇기 때문에 전후의 화면 사이에서도 깊은 의미를 가지고 있다. 이런 걸 특정 화면, 특정 기능에만 주목해서 보게 되는 사용자의 시점에서는 일련의 전체적인 흐름에 대해 보지 못해서 프로그램 개선을 망치게 될 수 있다.
그리고 이건 사실 사용자 뿐 아니라 영업 관점에서도 여러모로 말 나오는 이야기일 수 있다. 영업 입장에서는 사용자쪽을 이해 혹은 설득하는 듯한 작업 수순을 통해서 설명하고 그에 따른 이야기들을 듣고 오다보니 사용자쪽 시선에 갖춰져서 시선이 좁아지는 경우도 생기기 마련이기 때문에다. 그래서 영업과 개발이 싸우기도 하고…./먼산