Agile 프로세스에서 Pair Design하기
혼자보단 둘, 둘보다는 셋...?!
선배 한명이 회사차원에서 선진문물을 배워오겠다며 실리콘밸리의 Pivotal Labs라는 곳에 3개월동안 프로젝트를 다녀왔다. Pivotal Labs의 가장 큰 특징은 모든 역할자가 Pair로 일한다는 점인데, 영광스럽게도 그 선배의 Pair로 내가 선정되어 약 3개월동안 함께 디자인작업을 진행하게 되었다.
일하는 방식은 이전까지 각자의 컴퓨터를 이용하여 디자인하고 공유하던 방식에서 벗어나, 업무시간동안 컴퓨터 한대에 모니터, 키보드, 마우스 각각 2대씩 연결하여 한 사람은 작업하고 나머지 한 사람은 그걸 지켜보고 있는 형태였다. 완전히 새로운 형태로 일하는 방식이었기에 그때 느낀점을 공유해보려고 한다.
원래는 같은 화면을 두개의 모니터로 보고 있지만 지금은 모니터 색감차이때문에 하나의 모니터를 보고 있다. (내 신변의 안전을 위해 그녀들이 이 글을 보지 않았으면 좋겠다.)*만약 Pair Design에대해 알고 싶다면 이 글을 먼저 읽어볼것을 추천한다.
두치와 뿌꾸, 배트맨과 로빈, 홈즈와 왓슨
Pair Design을 한다고 전해 들었을 때, 가장 먼저 들었던 생각은 나와 그 선배와의 관계다. 그 선배와 나는 약 2년정도의 경력차이를 가지고 있고 이전에 일을 같이 해본적도 없었다. 심지어 사석에서도 몇 번 이야기 해본게 전부였던 상태였다. 또 우리 페어가 처음부터 끝까지 하나의 제품을 디자인하게 된다는 이야기를 들었을 때, 엄밀히 말해 비주얼 디자이너는 아니었던 나는 그저 선배를 보조하는 역할을 수행하게 될 것이라는 예상을 했었다. 홈즈와 왓슨의 관계처럼 말이다.
내가 생각한 우리의 관계, 물론 내가 왓슨이다하지만 막상 일을 시작하고 나니 전혀 다른 방식으로 일이 진행되었다. Agile 방식으로 일이 진행되었기 때문에 실제 개발이 시작되기 전 Design Phase가 선행되었는데, 그 선배는 나에게 컬러 스킴을 포함한 GUI style을 잡게 했으며(..) 심지어 그 디자인으로 개발까지 진행되었다..(!!)
선배가 멋진 디자인을 해 냈을 때 나의 반응Pair Design의 포인트는 '내것'이 없다는 것이다. 디자인 관련한 모든 결정은 디자이너의 손으로 이뤄져야하며, 거기에 '나'보다는 '우리'의 디자인이 되어야한다는 것. 그래서 모든 디자인 과정에 누군가 한사람의 손만 관여되서는 안된다. 완벽하게 둘의 의도가 일치된 상태에서 디자인을 진행하는 것. 그것이 핵심이라고 할 수 있다. 그렇기 때문에 누가 누구를 보조하거나 주도하는 입장이 되면 안된다. 서로 동등한 위치에서 본인의 생각을 솔직하게 말할 수 있는 환경이 되어야 '우리'의 디자인이 된다.
선배의 말이라고 무조건 따라서는 안된다일 할때 목이 아프다.
UX 필드에서 일하시는 분들이거나 사용자 리서치 방법론에 조금이라도 관심이 있는 분들은 Think Aloud에 대해 들어본 적 있을것이다. 사용자 리서치에서 인터뷰이가 본인의 생각을 입밖으로 내게 하여 어떤 의도를 가지고 그 행동을 했는지 관찰자로 하여금 인지 할 수 있도록 유도하는 방식이다.
페어디자인을 하는 가장 큰 장점으로는 디자인 리뷰시간이 사라진다는 것이다. 그것을 위해서는 일 할 때, Think aloud 할 수 밖에 없다. 따로 내 디자인에대해 설명하는 시간이 없다보니 어떤 의도를 가지고 지금 버튼을 여기에 배치하는 지, 라인의 의미는 무엇인지, 레이블은 어떤 기준으로 작성되는 지에 대해 내 페어에게 충분히 설명해야할 의무가 있다.
이전까지는 같은 화면을 각자 설계하고 리뷰시간을 가지던 방식으로 일을 했었다. 그때 느꼈던 단점은, 벤치마킹했던 혹은 머리속에 있는 UI를 일단 파워포인트로 옮기고 나중에 모두 함께 모여 공유하다보니 너무 많은 시간이 걸리며 어떤 사소한 문제들은 무시되거나 넘어가게 되는 경향이 있다는 것이다. (이런 식으로 넘어갔던 문제가 전체 시스템의 일관성이나 UI/GUI 표준을 어기게 되는 현상을 자주 목격하였다.)
가끔 내 페어가 내 말을 이런 식으로 듣고있다는 느낌을 받을 때가 있다..하지만 이렇게 Think aloud로 디자인을 진행하다보니 거의 모든 UI에 디자이너의 의도를 담는 연습이 되었다. 또 그렇게 생각하고 디자인하는 방식은 앞으로 내 일하는 방식에 큰 영향을 미치게 될 것이다. 더불어 상대방의 말을 주의깊게 듣는 것도 중요하다. 이런 과정을 통해 디자이너끼리 서로의 가치관과 의도를 완전히 투명하게 이해하게 된다.
현재에 집중하게 된다.
이것은 정말 어려운 일이고 아직까지도 잘 안되는 것 중 하나다. 페어이기 때문에 발생하는 특징은 아니고, Agile이라는 프로세스 내에서 디자인하기 때문인데. 현재 이터레이션에서 할 수 있는 best를 위해 미래의 걱정은 그때가서 하자는 것, 또 디자이너의 주장이 아니라 명확한 Fact만을 가지고 디자인을 하지는 것이 요지다. 예를 들면 이런 상황이다.
(회원정보 등록 화면 디자인 중)
나 : 여기에는 이메일 주소가 들어가고 여기에는 전화번호...아 핸드폰 번호는 필수로 지정해야겠지..?
페어 : 잠깐, 근데 어차피 필수 등록정보는 이메일만 있으면 되는거잖아? 그러니까 여기에는 이메일 주소 입력창만 두는 것으로 하자.
나 : ...아 근데 어차피 여기에 핸드폰번호랑 주소랑 다 들어갈 Form이 될거잖아..굳이 왜..(분노)
페어 : 현재 이터레이션 범위도 아니고 그 입력폼에 대한 정보도 부족해. 그러니 지금은..
나 : ...(마우스를 던지고 싶은 심정이다)
여기에 대한 나의 생각은 2가지인데. 일정 부분 이해가는 것도 있다. 디자이너가 사용자에게 검증받은 내용이 아닌 각자의 주장으로 일하다보면 명확하게 풀리지 않는 문제가 있다. 예를들면, 일반적이지 않은 버튼 형태를 삽입했을 때 그것이 명확한가 명확하지 않은가에 대한 디자이너 끼리의 논쟁이다. 결국 확인할 수 없는 문제로 인해 시간을 낭비할 수 밖에 없게된다. 따라서 최대한 디자이너의 가정을 배제하고 현재 밝혀진 Fact만을 기반으로 디자인하되. 빠른 Prototyping으로 자주 사용자를 만나 테스트를 해보는 것이 답이다.
성공적인 User validation을 끝냈을 때 우리의 모습반대 입장은, 먼 미래에 대해 걱정할 필요는 없지만 한발짝 앞의 미래에 대해서는 생각해 볼 필요가 있을 것 같다는 것이다. 예컨데, 회원정보 등록화면을 디자인하면서 검색 디자인에 대해 걱정할 필요는 없다. 다만, 회원정보 등록화면과 연계된 바로 다음 스텝. 휴대폰 인증이나 에러메시지 같은 엣지케이스들은 고려할수록 다음 일 진행에 도움이 되었다. 이것과 관련된 내용은 앞으로 더욱 진행해보면서 장단점을 파악해봐야 할 것 같다.
마치며
처음에는 짧고 간단하게 쓰려다가 할 말이 많아져서 없는 글 주변으로 긴 글을 쓰려니 정말 힘들었다. 내 의도가 모두 전달이 되었을지 모르겠다. 무엇보다 하고 싶은 이야기는 페어로 디자인 하는 것은 생각보다 훨씬 가치있는 일이며 특히 Agile 프로세스를 대응하기 위한 Velocity를 내는데 특화되어있다는 점이다. 그러기 위해서는 디자인 페어가 Full-stack 디자이너가 되어야 하는데, Full-stack 디자이너에 대한 이야기는 다음에 이어서..
