Ux Design + Mobile App

웹이 사람들의 세상에 들어오면서 수많은 정보들이 인터넷을 통해서 들어오기 시작했습니다. 필요한 정보 그리고 필요하지 않은 정보들까지 엄청난 양의 정보를 얻게 되었지요. 각종 직간접 광고부터 원하지 않은 정보들까지 한 페이지안에 넘쳐흐르고 있습니다. 이때문에 "원하지 않은 광고없이 웹페이지를 볼 날이 왔으면 좋겠구만!"이라고 생각하시던 분들이 계실것이라고 생각합니다.그 분들을 위해서, 여기 유명한 에버노트의 제작사가 '에버노트 클리어리'를 들고 왔습니다. 

사용하는 방법은 매우 간단합니다. 프로그램을 설치하고 웹브라우저의 오른쪽윗부분에 위치한 스탠드마크의 버튼을 누르면 페이지의 본문내용만 화면에 깨끗하게 나오고 광고나 다른 정보들은 모두 사라지게 되는 것이지요. 이러한 기능은 특히나 뉴스사이트에서 유용한 것 같습니다. 네이버나 다음을 통해 주요 뉴스에 접근하면 화면상에 난잡하게 자리잡고 있는 각종 광고들없이 화면을 볼 수 있게 된것이지요. 게다가 에버노트 사용자들은 광고없는 본문을 에버노트로 클리핑해 저장해둘수도 있으므로 매우 유용한 툴이 될 것같습니다. 

                        
개인적으로는 이것이 웹발전의 양날의 검이 될 수도 있다고 생각하는데요. 광고가 사용자에게는 필요악이 될 가능성이 높지만, 웹이 지금까지 발전하기까지에는 자금이 필요하고 그 자금은 광고로부터 나오는 것이지요. 지면의 광고를 완전 차단하는 방식은 아니지만, 기사를 읽는 동안 광고가 보이지 않는다는 것은 광고의 효율성이 떨어지게 되는 원인이 될 것입니다. 사용자에게 좋은 경험을 제공하는 이러한 프로그램이 웹세상의 발전에는 않좋은 영향을 끼칠수도 있다는 것입니다. 


아직까지 에버노트클리어리는 국내에서 많은 이용자수를 차지하고 있는 익스플로러에는 적용되지 않으므로 당장 큰 영향을 몰고 오지는 않겠군요. 조만간 익스플로러에서도 사용가능해진다면 웹의 진화에 무언가 변화를 몰고 오지 않을지 궁급해집니다. 한번 사용해 보시겠습니까? 아래에 다운로드 링크를 걸어놓았습니다. 그리고 크롬이 없으신분은 크롬을 미리 설치해야한다는 점 잊지 말아주세요!

크롬 다운로드 링크 ( http://www.google.com/chrome )
클리어리 다운로드 링크 (http://www.evernote.com/about/download/clearly.php)
 

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를 기존의 팀에 적용시키는 데 있어서 나타나는 문제점들과 해결방안에 대해 생각할있는 기회를 갖게 되어 많은 도움이 되었다고 생각합니다. 이 분이 관련 책도 낼 예정이라고 하시는 데 기대가 되어지네요. 

전체과정을 종이로 한번 만들어서 시뮬레이션을 해 보는 '페이퍼 프로토타이핑'을 해 봅시다. 대충 다 아는데 왜 굳이 그렇게 해야하냐구요? 하다보면 문제점들을 발견하게되고, 그러한 문제를 해결해 줌으로써 나중에 다시 수정을 하는 시간을 줄여줄 수 있으며, 프로젝트의 방향과 사용자의 경험에 대해서도 팀 전체가 생각해 볼 시간을 가질 수 있게되기때문이죠. 게다가 코드를 작성하지 않아도, 디자이너들이 색을 고르고, 그래픽스타일을 정하지않아도 됩니다. 모두가 알아볼 수 있는 글씨로, 실제 나올 비율과 어느 정도 비슷한 수준으로 만들면 충분하기 때문에 제작에 드는 시간도 그렇게 많지 않습니다. 

물론, 이러한 페이퍼프로토타이핑은 팀원모두가 프로젝트를 함께 이끌어나간다는 인식이 있을 때 힘을 발휘할 수 있다고 생각합니다. 예를 들어, 프로그래머는 UX설계에 대해 귀찮아하며, 기획자는 다른이들의 간섭을 싫어하고, 디자이너는 그래픽 디자인 작업이외에 해야할 일들이 늘어만 가는 것 같아 불만을 표시한다면 이러한 페이퍼 프로토타이핑도 결국엔 시간낭비가 되고 말겠지요.
 

얼마전 세미나에 가보니 요즘은 프로젝트를 할 때에도 기획자, 디자이너, 프로그래머가 기획단계에서부터 한 팀으로 움직이고 있으며, 이러한 과정들이 서로가 서로를 이해하고 좀 더 효율적인 제안을 하는데 도움이 되었다고 들었던 기억이 납니다. UX는 '백지장도 맞들면 낮다'는 옛날 속담이 적용되는 분야라고 생각합니다. 많은 이들의 피드백을 받고 보다 좋은 UX를 설계함에 있어서, 낮은 수준의 그래픽(러프한 스케치)으로 팀원모두가 초기에 참여가능한 시뮬레이션을 가능하게 해, 높은 효율의 결론도출을  이끄는 방법이 바로 '페이퍼 프로토타이핑' 이며 UX설계 과정에 있어 빠져서는 않될 중요한 과정이라고 생각합니다.
 

에스노그라피에 관한 인터넷 검색을 하는 중에 에스노그라피에 관한 설명이 들어있는 좋은 신문기사를 발견하였습니다. 사용자조사에 관한 공부를 하다보면 나오는 단어가 바로 이 '에스노그라피'입니다만, 좀 포괄적인 학문이라 그런지 어떻게 조사하는 것인지 잘 다가오지가 않습니다. 링크된 기사는 2008년 7월26일 조선일보에 게재된 글로서, 사용자조사에 대한 당시의 흐름을 알 수 있으며, 기사에 사용된 여러가지 단어들을 일반인들이 이해할 수 있도록 쉽게 풀어 놓아 UX를 공부하는 사람들에게도 개념을 이해하는데에 도움이 된다고 생각합니다. 
--> [ http://news.chosun.com/site/data/html_dir/2008/07/25/2008072500886.html ] 

                        사진은 (http://mktg343.pbworks.com/w/page/9973641/Ethnography%20-
                        %20Methods%20and%20Examples ) ethonnography관련해 실린 사진입니다.  

 기사중 주목해볼 점은 에스노그라피(Ethnography)란 단어입니다. 사실 이 단어는 좀 어려운 단어로 원래 뜻은 '민속학' 이란 뜻으로 영영사전을 직역하면 인간 문화에 대한 과학적 서술을 다루는 인류학'이라고 되어있습니다. 바로 확, 다가오지 않으시지요? 결국 사용자의 문화, 습관 등에 대해서 조사하는 것입니다.  예를 들면, 일본분들은 식사를 하실 때 밥그릇을 들고 먹으시지요. 그런 일본인에 대한 에스노그라피조사 없이 무겁고 아름답기만한 제품을 만든다면 팔리기 힘들겠지요. 사용자 설계를 함에 있어서도 이런 에스노그라피조사를 통해 문화적 , 관습적 행동에 대한 이해를 기초로 하는 것이 필요하다는 것입니다. 

기사중에는 기존에 특정시간에 사용자를 모아 인터뷰하는 방식보다 더욱 사용자에 밀착적인 (예를들면, 카메라를 달아 관찰한다든지, 사용자와 동행하며 조사한다든지 하는) 조사를 인류학자들이 특정집단을 조사하기위해 직접 관찰하던 방식과 비슷하다고 하여 '에스노그라피'라고 부른다고 쉽게 설명해 주고 있습니다. 2008년에 이 정도라면, 지금의 대기업은 이보다 더 발전된 기기를 이용하여 에스노그라피 조사를 하고 있지 않을까 하는 생각도 듭니다. 

이 기사이외에도 에스노그라피를 이해하는 데 도움이 되는 사이트가 있습니다. [ http://uxfactory.com/429 ]인데요. 이 곳에는 유엑스 관련 사이트 및 페이스북 UX그룹을 운영하시는 황리건님께서 작성해주신 글이 많이 실려있는 곳이지요. 이 페이지에는, 미국과 일본의 전쟁중에 미국이 일본문화에 대한 이해를 위해 루스 베네딕트라는 인류학자에게 일본에 대한 보고서를 쓰게 했다는 에스노그라피의 오래된 사례또한 알려주시고 있습니다. 

사용자를 즐겁고 행복하게 하기위해 하는 UX에서 사용자 조사는 매우 중요한 것이라고 생각이 되며, 경우에 따라서 에쓰노그라피 조사 또한 매우 중요하다고 생각이 되어집니다.   

제 블로그를 통해서 여러번 언급되었던 페르소나에 대해서 좀 더 알아보도록 하겠습니다. 다시 한번 그 정의에 대해서 짚고 가면서 시작해보겠습니다. 페르소나라는 것은 타겟 고객, 즉 사용자를 정의한 가상의 인물 또는 문서를 애기합니다. 이런 예는 어떨까 합니다. '무릎팍 도사'에서 강호동은 그만의 캐릭터를 만들어 쇼에서 표출합니다. 큰소리 탕탕치면서 말도 않되는 해결책을 제시해주는 무릎팍 도사라는 캐릭터말입니다. 이 캐릭터는 티비시청자들을 위해서 만든 캐릭터입니다. 이런식으로 만든 캐가공의 릭터가 바로 페르소나이지요. 다만 차이점은 무릎팍도사라는 캐릭터는 시청자에게 재미를 주기위한 현실에 없을 것같은 캐릭터이고 페르소나는 대표적인 시청자들을 캐릭터로 정의하여 분류한 것입니다. 

UX디자인 과정에서 페르소나를 정하는, 그리고 이것이 중요한 이유는  UX design, 즉 사용자 경험 디자인의 대상은 사용자이기 때문입니다. 사용자를 만족시키기 위해, 행복을 주기 위해 디자인하는 것이 UX디자인인 것인데 이러한 사용자에 대한 정의없이, 개별적으로 제기된 문제에 대해 제작자가 이러면 좋을 것 같다 저러면 좋을 것 같다고 하면서 문제해결이 사용자가 아닌 제작자의 시각에서 이루어지는 것을 막을 수 있기 때문이다. "이건 이러면 좋지 않아?"보다는 "24세살의 강남에 살며, 자동차를 몰고다니고 아이티 기기에 관심이 많은 대학생 김모세는 ~한 방식을 선호할 것이다." 라고 보다 정확하게 사용자의 시점으로 판단할 수 있기 때문입니다.  

                        (사진은 http://www.bolducpress.com/design/user-personas-and-how-they-can-im
                         prove-your-site/  에서 소개한 Persona의 예입니다.)

이러한 페르소나는 보다 자세할 수록 좋습니다. 그런데 이러한 페르소나가 크게는 두가지로 나뉩니다. 하나는 마케팅에 있어서 사용되는 페르소나로 구매동기를 가진 가상캐릭터이고, 두번째는 인터랙션 디자인에 있어서 인터랙션을 정의하기 위한 가상 캐릭터입니다. 둘다 중요한 것이며, UX디자인에서 다루는 것은 주로 후자쪽입니다.

실무에서 사용되는 예를 생각해보면 다음과 같습니다. 기획단계를 거쳐서 여러가지 문제를 해결하고 문제에 봉착했을 때, 흔들리지 않는 중심을 잡아줍니다. 나라면 이것을 이렇게 할 것이다가 아니고, 우리의 페르소나 브라이언은 이런 방식을 불편해할 것이다. 혹은 우리의 페르소나 셀리는 귀엽고 아기자기한 디자인을 좋아할 것이다,라는 식으로 사용자에 대해 좀더 몰입하여 문제해결을 할 수 있다는 것이지요. 

또한 페르소나를 제대로 정의하지 않고 가면, 페르소나를 한두개 정의했다고 해도, 디자인을 해가면, 혹은 개발을 해가면서, 우리의 대상은 우리가 정했던 페르소나가 아닌것 같다. 라는 결론에 다다르고 다시 처음부터 시작하던지, 기존의 개발자 시선의 문제해결로 문제를 풀어가게 되는 것입니다.

네, 페르소나는 매우 중요한 것이군요. 프로젝트를 이끄는 모든이들이 이의 중요성을 알고 사용자 중심으로 문제를 해결하여 좋은 하드웨어를 , 소프트웨어를, 서비스를 만들 수 있었으면 합니다.   

오늘 열린 대종상 영화제를 티비를 통해서 보았습니다. UX를 공부하고 있어서 그런지, UX의 관점에서 다시 한번 영화제를 되짚어 보고자 합니다.

대종상영화제는 대한민국 최고의 권위와 역사를 가진 영화제입니다.  이 영화제는 누구를 위해 만든 무엇을 하기위한 영화제 일까요? 우선, 영화를 만든 영화인들의 그동안의 노력과 예술성에 대해 상을 주는 것일 거구요. 티비로 보아도 앞좌석에 많은 자리를 차지하고 앉아계시는 스타들의 모습을 보니 틀림없는 사실이군요. 그렇다면 관객은 어떻게 되나요? 이 영화제에는 관객이 대종상영화제를 기획하는데 있어서 고려대상에 들어가 있는 걸까요?

다시 UX의 개념으로 말하자면, 대종상 영화제에는 관객을 페르소나(페르소나 관련해서는 제가 페르소나에 관해 포스팅한 글을 보시면 더욱 알기 쉬우실 것 입니다.) 의 일부로 설정한 걸 까요? 물론 그렇기는 하겠죠. 다만,  제1페르소나와 제2페르소나 혹은 그 아래의 페르소나 중 관객은 어느정도에 위치해 있을까요? 관객이 이 영화제에 있어 우선적으로 만족시킬 제1페르소나로설정 된 것일까요? 아니면 그 시상식에 참여한 영화인들이 제1페르소나가 되어 있는 것일까요?

누구를 우선으로 할 것인지는 차치하고 제가 영화제를 본 바로는 기획하시는 분이 영화인들을 제1페르소나로 잡지는 않았다고 생각 합니다. 영화제를 보고자 하는 관객을 위한 시상식이라면 좀더 관객이 즐길 수 있고 , 영화제에 대한 일관적인 내용을 알려야 하는게 맞겠지요. 첫 화면부터 '최종병기 활'을 연상시키려고 했는지 영화시상식에 갑자기 뮤지컬비슷한 춤을 추는 장면을 공연하고, 이 후에 '소녀시대' 가 무대에 나왔습니다. 누구를 또 무엇을 위한 최종병기 활 무대 재현인가요? 소녀시대가 나오는 것은 (물론 개인적으로야 환영할 만한 일이지만) 또 무슨 연유일까요? 

계속이어지는 구성은 아주 단순 합니다. 시상자 발표 + 엠씨의 농담 + 연예인 공연(무대의 쉬크한 반응) 이죠. '단순 시상식 + 뮤직뱅크'와 크게 다를바가 없네요. 엠시뒤에 세워진 병풍같은 배경과 조금 부족해 보이는 조명등은 이 시상식이 그렇게 화려하고 대단한 영화제라는 인상을 주기에도 조금 부족하지 않나하는 생각이 들었습니다. 레드카펫에 오기까지는 얼마나 화려햇는지 모르겠습니다만 말입니다. 

이번 대종상 시상식은 관객이나 방송 시청자들을 제1페르소나, 즉 가장 중요한 대상으로 고려한 것이 아니라는 생각이 들었습니다. 관객을 초대하고 관련 방송을 내보내고 언론에 알리는 시상식이라면, 관객을 (UX관점에서의 사용자) 먼저 생각하고, 관객이 영화와 관련하여 즐길수 있는 구성이 되었으면 더욱 좋지 않았을까 하고 생각해봅니다.  
 

많은 인터랙션 디자인회사에서 사용되고 있는 발사믹이라는 툴을 좀 더 구체적으로 소개하고 제 경험을 바탕으로 생각을 공유하고자 합니다. 

우선 앱이나 웹관련 프로젝트가 진행되고있다고 가정을 합니다. 어느정도 진행되면 디자이너가 디자인을 팀과 공유를 하는 데 있어서 고민을 하게 됩니다. 아... 이걸 어떻게 공유하면 좋을까. 스케치한것을 사진을 찍어 흐름을 보여드려야 할까? 아니면 벽에다 붙여서 보여드려야 하나? 

물론 초반 러프스케치후 팀원들의 피드백을 받어나가는 과정을 거쳐나갈때는 괜찮습니다. 하지만, 어느정도 틀이 잡히고 개발팀에서 기본적인 로직개발을 해나가야 할 때 문제가 됩니다. 포토샵으로 이미지를 완성시켜서 주는 것은 시간이 많이 걸려 비효율적일 뿐 아니라. 계속 디자인을 변경시키며 발전시켜나가는 데에도 시간이 많이 걸립니다. 그렇다면 역시 스케치나 와이어프레임스케치를 사진으로 찍어서 공유하는 것이 맞지만, 그렇게만 하는데도 시간이 걸리는 것이 사실입니다.

이럴때 나와서 등장하는 히어로는 바로 '발사믹'이라는 프로그램입니다. 디자이너들이 많이 쓰는 앱이나 웹의 버튼들의 스케치한 이미지들을 자유롭게 넣다 뺄수 있고, 플로우를 쉽게 볼수 있도록 변형이 자유로운 '화살표'를 제공합니다. 한 화면안에 여러장의 화면을 넣고 그 흐름을 보여줄 수 있으며, 확대 및 축소도 가능합니다.

쓸데 없는 부분에 시간을 많이 들이지 않고, 효율적으로 아이디어를 공유할 수 있다는 면에서 매우 좋은 프로그램이라고 생각합니다. 하지만 단점이라면, 아이폰이외에 안드로이드에 대해서는 기본 유아이를 제공해주지 않고 있으며, 공유하는 팀원전체가 발사믹을 가지고 있지않으면 않된다는 점에서 규모가 작은 회사들이 채용하기에는 비용이 조금 든다는 점이 있습니다.
  
발사믹은 팀원간 공유하는데 있어서 효율을 높여주고 커뮤니케이션 에러를 줄여주는 좋은 프로그램이라고 생각합니다. . 하지만 디자이너로서 스케치과정없이, 발사믹 툴에 의존하여 프로그램이 제공하는 유아이로만 디자인을 하게 된다면, 자유롭고 실험적인 디자인을 하는데에 장벽이 되지 않을까하는 우려가 드는 것도 사실입니다. 발사믹을 스케치툴로 사용하지않고 팀원간 커뮤니케이션을 위한 '목업툴'로서 활용한다면 프로젝트의 효율을 높이는데 도움이 될 것이라고 생각합니다.  
 

회사에서 업무를 진행하다 보면 정해진 시간안에 여러개의 안중에 하나를 결정해야 할 경우가 있다.
유엑스의 경우도 마찬가지라고 생각한다. 사용자 경험조사에 예산을 소비할 수 없는 작은 회사들의 경우 팀내에서 서로 설득을 해가며 결론을 도출해야만 하는데 이럴때 어떻게 하는것이 좋을지 생각해보겠습니다.

예를들어, 두가지 레이아웃이 나왔고 이중 하나를 결정해야 한다고 하면, 
첫번째 방법, 팀 구성원의 대다수가 선호하는 것은 사용자 대다수가 선호할 가능성이 높은 것으로보고 그것으로 정하는 것이다.
두번째 방법, 사용자 전체가 만장일치에 가깝게 인정하는 안이 나올때까지 다른 안을 만들어 내는 것이다.

세번째 방법, 스티브 잡스와 같은 능력있는 최고 결정권자의 혜안으로 나온 안중 가장 적합안 안을 선택한다. 물론 잡스와 같은능력을 가진 결정권자가 작은 규모의 회사에 존재한다는 사실자체가 현실적이지 않다. 

이 세가지 방법 중 어떠한 방법을 선택하는 것이 좋을까? 개인적으로 생각하기에 최악의 시나리오는 첫번째이다. 시간에 맞추어 다수결로 정하고, 문제가 생기면 바꾸는 방법이 물론 가장 대중적인 방법이기도 하다. 디자인 개발단계에서 노가다 작업을 하게되는 원인이기도 하다. 두번째 방법이 좋기는 하지만, 프로젝트를 진행함에 있어서 시간이라는 요소를 절대로 무시할 수 없으므로, 이 또한 독불장군 식으로 진행해 나갈수는 없는 일이다.  

그러므로, 나중에 수정을 하는 데 드는 인력 및 시간등의 필요 리소스를 계산해보면 역시 사용자조사등 백데이터가 필요하다는 원칙으로 다시 돌아오게 된다.  결국 다수결 결정으로 인한 리스크를 감수하기도, 스티브잡스를 데려오기도 힘들다면, 테스트를 하고 그 데이터를 바탕으로 의사를 결정하는 일은 꼭 필요하다고 생각하게 되었다.
 

다음,네이버,네이트,파란은 국내 4대 포털서비스입니다. 이런 큰 기업에서 많은 인력과 시간을 가지고 진행하는 UX설계과정과 소규모 벤처회사에서 진행하는 과정은 달라질 수 밖에 없습니다. 하지만, 인력이 적고 시간이 없다고 해서 중요한 과정들을 무시하고 나간다면 그 만큼 퀄리티도 떨어지게 됩니다.

그래서 생각해 보았습니다.소규모 회사에서 적용하는 UX 디자인의 적용 과정과 순서입니다.
1.  6하원칙에 따른 타겟 유저 분석
    누가,언제, 무엇을 어떻게,왜, 어디서를 정의합니다.

2.  페르소나 설정 --> 시나리오 작성
    타겟 유저분석에 따른 페르소나를 설정해봅니다. 되도록 현실적으로 페르소나를 실제 인물로 가정하고 진행을 해봅니다.
    또한 그렇게 설정된 페르소나를 바탕으로 시나리오를 작성해보도록 합니다.

3. 경쟁사 벤치마킹, 자사 강약점 분석, 디바이스 환경분석, 러프스케치
    -->이 때 러프스케치에는 되도록 많은 사람들이 참여하며, 
           제대로 만들려고 하기보다는 러프하게 만들고 피드백 만드는 과정을 반복하여 보강해나간다.

4. 분석결과  리포트, 키워드 도출, 브레인스토밍,  플로우 스케치

5. 프로토 타입 작성 (발사믹 이용 혹은 종이프로토 타입도 괜찬음)

6. 주요화면 설계, 기능정의서, 가이드 작성 

이상에 제가 생각한 소규모 벤처회사의 UX디자인 적용과정입니다. 가장 큰 문제는 저런 상황을 적용하면서 사용자 분석데이터를 가지지 못한다는 문제입니다. 백데이터 없이 진행하는 과정으로서 생기는 여러 문제가 있겠지만, 믿을만한 사용자 분석을 할만한 예산이 않된다면 적어도 저런 방식으로라도 나가야 한다는 것이 제 생각입니다. 

아직도 대부분의 작은 회사에선 대충 기획하고 디자이너에게 보기좋게 디자인해달라고 한다음 되도록 빨리  개발자에게 전달하게 하여, 우선은 기본적인 기능을 사용할 수 있고 보기 좋지 않으면 괜찮다는 방식을 취하고 있습니다. 적어도 위와 같은 과정만이라도 소규모 인원끼리는 적용이 가능하므로 꼭 적용해 나갔으면 합니다.