Ux Design + Mobile App

LeanUX에 관해서 좀 더 알아보고자 합니다. 네이버 영한 사전을 잠시 찾아보면, Lean의 의미는 '기대다'와 '야윈,마른'등의 뜻이 있습니다. 이 중 LeanUX는 두번째 야윈,마른 쪽의 의미에 가깝습니다. 차에 관심이 좀 있으신 분이면 자동차 모델중에 LeanBurn이라는 모델명이 붙은 차종을 아시나요? 기름이 적게타는 정도의 의미로 쓰이지요. 적은 시간을 들여서 최대한의 효율을 만드는 UX정도로 정의 할 수 있겠습니다.

그럼 어떻게 짧은 시간에 효율적인 UX가 가능한 걸까요? 다이어트와 마찬가지입니다. 군살을 빼는거지요. 빼는 방법은 다음과 같습니다. 기존에는 기획자가 기획을 한후 디자이너들이 그래픽을 완성시킨후 개발을 거쳐 사용자테스트를 해 최종제품을 완성시켰습니다. 하지만, Lean UX는 다릅니다. 디자이너들이 그래픽을 완성시키지 않고, 모두가 스케치를 하고 스케치 상태에서 서비스에 대해 토론 및 발전을 시켜나가서, 종이로 프로토타이핑을 하는 것입니다. 그러므로서, 디자이너들이 그래픽에 들이는간과 그것을 수정해 다시 만드는 시간, 또한 개발자들이 디자인 나올때까지 대기하는 시간들을 줄이는 것이지요. 

크게 Lean UX의 사이클은 다음과 같습니다. Think-->Make-->Check 의 완성까지의 무한 반복이지요. 특히 Make에 관한 부분이 스케치와 종이 프로토타이핑 정도로 끝나기 때문에 보다 빠른 시간안에 피드백을 받아 향상시켜나간다는 점에서 개발속도의 효율성은 매우 좋아지게 됩니다. 또한 Think의 시간도 되도록 적게 하고 체크해서 피드백을 받기까지의 시간을 최소화로 한다는 점도 하나의 원칙으로 볼 수 있는데요. 이부분에서도 효율을 나타내게 되는 것이죠. 오랫동안 고민하는 것보다는 빠르게 만들고 피드백을 받으며 더욱 좋은 것을 빠른시간안에 찾을 수 있기때문입니다.

LeanUX 가 매우 좋기는 하지만, 팀 전체의 이해화 협력이 없으면 실현하는 데 여러가지 어려움이 있을 것이라고 생각합니다. 팀전체의 동의와 협조를 이루어 내기위해 프로젝트매니저의 역할또한 매우 중요하게 생각되어집니다. 또한 그래픽적으로 완성되지 않은상태에서의 UX설계와 접근이기 때문에, UX이외의 그래픽적 접근에만 얽매여 있게된다면 LeanUX를 하는데 방해가 될 수 있겟습니다. LeanUX, 어떻게 보면 스케치만으로 설계하는 UX라고도 할 수 있겠네요.

SmamshingMagazine에 글을 쓴 바 있는 Jeff Gothelf 님께서 TheLadders.com이라고 하는 구인구직사이트를 운영하는 회사에서 Agile+ LeanUX를 적용한 사례를 적은 글을 발견하였습니다. 전통적인 방식으로 사용자경험을 설계하는 회사에서 어떻게 Agile+ LeanUX를 적용시키는 것이 좋을 지에 대해 많은 답을 줄 수 있을 것 같습니다. 
-->( http://johnnyholland.org/2010/10/21/beyond-staggered-sprints-how-theladders-com-integrated-ux-into-agile/ )

원래 이 회사의 UX팀은 전통적인 워터폴방식(직역하면 폭포방식이라고 할수있을까요? 위에서 승인해주면 그다음 단계를 진행하는 전형적인 업무 방식, 피드백을 받는 것이 느리고 적용과 수정에도 시간이 걸리는 방식) 을 취하고 있었다고 합니다. 즉 서비스 기획을 하고 승인을 받은 후 디자이너가 디자인을 다하고 승인을 받고 개발자에게 넘기고 코딩을 하여 서비스를 완성하는 방식을 취하고 있었던 거지요. 

Jeff Gothelf님은 기존의 방식에 익숙한 UX팀에 Agile + LeanUx를 적용시키기 위해 했던 시도들을 총4단계로 나누어 설명해 주시면서,그 속에서의 실패와 성공에 관해서 글에 자세히 적어주셨습니다.  그 4가지 단계중에 눈에 뛰는게 3번째 시도에 나오는 '사용자 테스트'인데요. 좀더 자주, 형식화되지 않은 방식으로 테스트를 하기위해 다음과 같은 규칙들을 세우게 되었다고 합니다. 

• 사용자테스트는 한번에 3명 미만으로
• 같은 날 같은 시간에 매주 테스트
• 테스트시 그것이 단순한 스케치라고 할지라도 준비된 모든 것을 보여준다.
• 인터랙션에 있어서 장애물을 제거하는데 테스트를 이용한다.
• 2주후 남은 시간을 디자인 및 만든 서비스를 유저들과 제확인하는 데 사용할 것.
   

이러한 규칙들을 토대로 좀더 정형화되지 않고 자주 테스트를 수행하여 반영한다는 것은 실제 제작하는데 있어서도 적용해 볼만한 것이라고 생각합니다. 그리고 디자인 리뷰에 관한 글도 관심이 가서 보게 되었는데요.

"한번의 턴(만들어서 팀에서 회고를 하기까지를 하나의 턴으로 보고) 에 두번의 디자인 리뷰를 진행하였습니다. 하나는 중반에 마지막은 완성이틀전에 하게 됩니다. 디자인은 95점정도가 되어야 되고 그렇지 않다면 UX팀은 다시한번 2주동안 수정을 하기위해 달리게 되는 것이지요. 그리고 이러한 과정에, 디자이너가 필요로한다면, 특별한리뷰를  한번더 진행되게 됩니다. 디자인 리뷰에 있어서 참석이 매우 중요하므로, 시간과 요일을 똑같이 맞추어 진행하였습니다. 그리고 리뷰에 참석하지 않는다면 그 디자인을 인정한다는 의미로 해석하겠다고 하였는데, 결과적으로 출석률은 매우 좋았습니다. "

결론부분에서 Jeff Gothelf님은 이렇게 말하였습니다. "첫번째 스텝은 커뮤니케이션이지만, 최종적인 목표는 서로를 신뢰하는 것이다." 서로에 대한 신뢰없이는 Agile + Ux디자인도 쉽지많은 않다는 것이지요. 팀작업을 베이스로 하는 Agile의 특성을 잘 반영하고 있는 말이라고 생각합니다.

 Jeff Gothelf님의 글을 보면서 Agile+LeanUX를 기존의 팀에 적용시키는 데 있어서 나타나는 문제점들과 해결방안에 대해 생각할있는 기회를 갖게 되어 많은 도움이 되었다고 생각합니다. 이 분이 관련 책도 낼 예정이라고 하시는 데 기대가 되어지네요.