안녕하세요? 오픈마루 아톰입니다. 이 글은 아톰 저의 이야기 입니다.  

간만에 포스팅으로 뵙는 것 같습니다. 이번 포스팅에서는 지난 11월 26일(수)에 삼성 SDS 멀티캠퍼스에서 UX와 관련된 Forum이 있어 Forum의 내용과 저의 생각들(?)을 정리해보고자 합니다 ^^

과거의 이런 Forum이나 컨퍼런스에서는 대부분 개론적인 내용이 많아서 적잖이 실망을 하기도 했었는데 요번에는 개인적으로, 생각보다 얻을 것이 있었던 자리가 아니었나 하는 생각이 듭니다.

이번 Forum은 크게 두개의 세션으로 구성되
었는데요. 요약하자면 다음과 같습니다.
[사진 출처: 블로그 부러진 날개를 펴다]

• Session 1 : UX에 대한 소개(정의) 및 UX를 향상 시킬 수 있는 스킬(?) 향상을 위한 Tool 안내
• Session 2 : 웹 사이트 평가 방법론

1. Session 1

• UX의 정의
  UX에 대한 정의는 그 정의를 내리는 주체에 따라 조금씩 다르게 표현하지만 결국 가장 근본적인 요소는 사용자라는 것은 누구나 아는 내용이다.
  사람과 개체(PC, Mobile 등)간 일어나는 사용 목적, 주의 그리고 Task들은 인간의 행동, 환경, 문화의 영향을 받아 이루어지기 때문에 단순히 인터페이스(UI)를 넘어서는 요소들도 고려의 대상이다.

• UX 개발 프로세스
  Research 단계 --> Experience Planning 단계 --> Experience Briefing 단계 --> Experience Design 단계 --> Experience Roadmap 단계
  각 단계별로 상황에 맞는 방법론이 존재한다.(이는 각 회사별로 다를 것 같네요)
  여기서 가장 중요한 부분이 "Experience Briefing 단계"라고 강조하고 있는데요. 이는 본격적인 개발 이전에 팀 내부의 명확한 합의 및 의사결정자들의 설득을 위한 단계로 프로젝트의 진행을 위해서는 반드시 거쳐야 하는 단계라고 말하고 있습니다. 흔히 실제 개발보다 더 어려운건 의사결정자들을 설득하는 것이라고들 하는데 이러한 점을 반영한 것이라고 생각 됩니다.

• UX팀 구성
  Information Archietct + Interaction Designer + Usability Engineer + Visual Designer + Prototype Engineer로 구성하는 것이 최적이라고 합니다.
  아주 이상적인 팀 구성인데요. 이렇게 실제 구성하는 회사가 얼마나 될지는 의문이네요.
  우리나라의 현실에서는 Information Archietct + Interaction Designer + Usability Engineer = 기획자 / Visual Designer = 디자이너 / Prototype Engineer = 개발자가 아닐까 생각해봅니다. 여담입니다만, 오픈마루도 최대한 최적의 UX팀 구성, 팀웍을 위해 꾸준히 노력하고 있답니다 ^^

• UX 트렌드
  • Reality based Interface
    정의 : 현실에서 생활하면서 습득한 주변과의 상호작용 방식을 그대로 확장하여 제품이나 시스템에 사용할 수 있는 인터페이스
    Haptic/Gesture/안면인식/음성인식 등의 기술로 대변되는 인터페이스로 하드웨어적인 기술의 발전으로 점점 그 실현가능성이 높아지고 있다고 합니다.
    Haptic의 경우 이미 모바일 기기에서 많이 사용하고 있고, 이외 Bumtop이나 Smart skin 등이 있는데 실제 검색을 통해서 웹 사이트나 동영상을 보실 수 있습니다.
    또한 RIA 기술의 도래로 기존의 UI와는 다른 색다른 경험을 제공하고 있고 앞으로 발전이 예상된다고 하네요.

• Seamless Interface
  정의 : Computer, Game Console, IPTV, Mobile 등 다양한 Device에 두루 사용 가능하고 Multi-Function을 표현 가능한 인터페이스
  현재는 Mobile 기기나 Game 기기에서 많이 적용되고 있는 인터페이스로 Full-Browser가 대표적인 예라고 할 수 있고,
  Apple iPhone & iTunes와 Google Android 등에서 적용되고 있고, 게임에서는 Nintendo Wiimote, PS3 및 XBOX360 등에서도 적용되고 있다고 합니다.

• RIA 기술
  현재 UX를 가장 잘 표현할 수 있는 인터페이스 방식으로 RIA를 말하고 있는데, 많은 분들이 아시다시피 대표적으로 FLEX, JavaFX 및 Silverlight가 있습니다.
  각 기술들이 워낙 많은 자료들이 있는 만큼 자세한 내용은 쉽게 접근하실 수 있을 것 같은데, JavaFX는 아직 개발이 완성된 것이 아니라고 하니 참고하시면 되겠습니다.
  세션의 마지막에 3개 기술의 장단점을 비교해 주셨는데 제가 볼때는 여전히 FLEX가 좋은데 JavaFX 또한 막강한 도구임은 분명한 것 같습니만, 이 또한 각 상황에 따라 맞는 기술을 사용하면 될 것 같습니다.
   

2. Session 2

개인적으로 사용자 조사를 담당하고 있기 때문에 두번째 세션이 가장 인상 깊었는데, 이유는 그 동안 사용자 조사 시 언제나 가지고 있던 근질근질한 부분을 상당 부분 긁어주셨기 때문입니다.^^

대부분의 사용자 조사는 크게 정량적, 정성적 조사를 하게 되는데 그 영역간 Sealess한 연계가 어렵고 또한 잘 하려고 하지 않았던 것이 사실이지만, 세션2에서 전달하고 있는 내용은 정량과 정성조사를 자연스럽게 연계하여 원하는 데이터를 얻을 수 있는 방법에 대한 소개였고 개인적으로는 상당히 인상적이었습니다 ^^

이 방법론을 전민수 이비피알 컨설팅 대표께서는 SQI(Service Quality Index)라고 명명하셨는데 핵심은 다음과 같습니다.

• 정량의 방법으로 정성의 내용을 묻다.
  즉, '온라인 서베이에서 객관식이 아닌 주관식으로 묻는다' 입니다.

• 답변에서 서비스의 만족/불만족/경쟁사 이미지 등을 추출한다.
  분석자의 눈물나는 노력이 필요한 부분입니다.

• Index화 한다.
  정성의 내용을 정량화(수치화) 한다는 것으로 비율이 충분히 나올 수 있을 것입니다.
  이에 따라 각 서비스 구성 요소들 마다의 중요도가 산출될 수 있고, 개선의 우선 순위가 도출됩니다.

• UT를 통한 검증을 수행한다. 필요하다면 FGI도 수행한다.
  UT를 통해 최종 문제점이 확정되는 단계입니다. 개인적으로 FGI는 비추하고 있는데, 연계된 방법으로 일환으로써 FGI는 나름 큰 효과를 볼 수도 있겠다라는 생각을 해봤습니다.

내용 자체는 간단하게 보일 수 있지만, 실제 수행하기 위해서는 상당한 노력이 수반되는 방법론인데 효과는 나쁘지 않을 것 같습니다.

UT만 하면 문제점이 모두 나오고 온라인 서베이만 하면 사용자의 Needs를 파악할 수 있다는 안이한 방법에서 좀 더 논리적이고 구체적인 사용자 조사 방법이 아닌가 하는 생각이 들었습니다.

• 지난 포럼 볼수 있는 곳

이상으로 이번 Forum의 내용을 정리해봤는데요. 적다보니 생각보다  글의 양이 많아 졌네요^^; 긴글 끝까지 읽어주셔서 감사합니다.
이상 오픈마루의 UR의 아톰이었습니다~! 

                                                                                     

  [사진 출처: 네이버 이미지]

안녕하세요? 스프링노트팀의 강규영 입니다. 좀 늦었지만 그래도 후기를 올립니다 ^^

저는 UI에 관련된 주제들만 듣고 왔습니다:

• HCI/RIA를 통한 미래가치 창출
• Better Web, Better UX를 위한 Microsoft의 차세대 웹 전략, Silverlight & Windows Live Service

아래 세션은 (제 기대와 달리) 3D UI에 대한 이야기 아니라 주로 하드웨어나 3D 영상 등에 대한 내용이었어요:

• 3Di 비즈니스모델의 가능성
• 3D 인터넷 산업의 활성화 정책 방향

이중에서, 세번째 트랙의 첫번째 세션인 "HCI/RIA를 통한 미래가치 창출"이 재미있었는데요 다음 커뮤니케이션 UI Engineering 팀의 전정환님의 세션이었습니다. 발표 자료 중간 중간에 아는 분들 얼굴도 나오고 해서 특히 재미있게 봤습니다. 간단히 요약하자면 "한메일 익스프레스 개발 사례를 통해 살펴보는 RIA 개발 방법론 소개"입니다. 앞 부분에서는 HCI와 RIA 개념, 웹 2.0과 HCI 등을 간단하게 소개해주셨는데 이 부분은 생략하도록 하고, 프로세스나 방법론에 대해 말씀해주신 중간 부분부터 요약하겠습니다.

우선, RIA 프로젝트를 진행할 때 기존의 흔한 서비스 개발 프로세스를 그대로 적용할 경우 발생하는 문제들을 지적하고 있는데:

• 파워포인트로 작성된 두꺼운 기획서
• 기획 단계와 개발 단계의 엄격한 분리
• 팀간 커뮤니케이션의 어려움
  

등을 언급하셨습니다. 사실 이러한 문제는 기존에도 존재했지만 RIA 프로젝트의 특성 즉, 풍부한 사용자 경험을 제공하는 애플리케이션을 개발해야 한다는 특성으로 인해 기존에 존재하던 문제들이 더욱 부각되는 것이 아닐까 하는 생각을 해보았습니다. 예를 들어 동적이고 풍부한 사용자 인터페이스를 기술하기 위한 수단으로 파워포인트 기반 기획 문서는 그다지 비용-효과적인 방법이 아닙니다, 또, 기존에 존재하는 표준 인터페이스 이외의 새로운 인터페이스를 개발하고 사용자 경험을 향상시키기 위한 여러가지 실험을 해야하는 RIA 프로젝트의 경우, 기획/디자인/개발 단계를 엄격하게 분리하는 것은 작업 효율을 크게 저하시키는 요인이 될 수 있습니다.

한메일 익스프레스 프로젝트에서는 이 문제에 대한 대안으로 사용자 중심 디자인(User Centered Design - UCD)과 기민한 개발 방법(Agile Development)을 혼합한 프로세스를 적용했다고 합니다. 구체적인 실천법(practice)으로는 다음과 같은 것들을 언급했습니다:

• 페이퍼 프로토타이핑과 롤플래잉
• 화면 디자인이 붙지 않은 초기 단계부터 사용자를 참여시키고 피드백을 받기
• 반복적(iterative) 개발
  

첫번째로 언급된 페이퍼 프로토타이핑과 롤플래잉은 종이와 연필(그리고 사람 ^^)만 있으면 당장 해볼 수 있는 훌륭한 기법 중 하나입니다. 새로운 UI를 적은 비용으로 단기간에 실험해볼 수 있다는 표면적인 장점 이외에도, 기획/개발/디자인 직군 간의 대화와 협업을 장려한다는 숨은 장점도 갖습니다. 스프링노트 팀에서도 이 기법을 변형하여 종종 사용하는데, 며칠 전에는 툴바/다이얼로그 개선안에 대해 "포토샵"을 이용한 롤플래잉을 시도해보기도 했습니다, 손이 빠른 디자이너가 포토샵을 조작하여(레이어를 크고 켜거나, 순식간에 요소들을 이리저리 옮겨가면서) 이런저런 UI를 시뮬레이션 해주는 것이죠. 좋은 경험이었습니다.

두번째로는, 개발 속도를 빠르게 하기 위해 화면 디자인이 없는 상태에서 기능 일부를 먼저 구현하는 방식을 소개해주셨는데, 이 방식에는 장단점이 있을 것 같습니다. 예를 들어 "루비 온 레일즈"로 유명한 37signals 에서는 "Getting Real"이라는 책에서 화면 디자인을 가장 먼저 하는 방식을 추천한 바 있습니다. 발표가 끝나고 질문을 할 기회가 생겨서 이 방법에 대해서는 어떻게 생각하시는지 질문을 했었는데, 제 질문 의도가 명확하게 전달되지 않을 것 같았어요. 세션이 끝난 후 휴식시간에 쇼파에서 쉬다가(이 글을 적고 있었어요 ㅎㅎ) 우연히 전정환님, 그리고 같은 팀의 정규돈님을 만나서 이 문제에 대해 이야기를 더 나눌 수 있었습니다. 사이트 특성에 따라 화면 디자인을 붙이는 적절한 순서가 있을텐데, 한메일 익스프레스 프로젝트의 경우에는 기능 구현을 먼저 하는 방법이 더 적당하다고 판단했고, 현재에도 새 기능을 추가할 때 디자인 없이 기능 구현을 먼저 하는 순서를 따르고 있다고 합니다. 참고로 스프링노트 팀에서는 주로 화면 디자인을 먼저하는 방식으로 하고 있습니다.

마지막으로 소개해주신 반복적 개발(iterative development)은 일주일에서 한달 정도의 짧은 주기를 반복하면서 점진적으로 기능을 추가/개선하는 방식을 말하는데, 이 또한 여러가지 장점이 있는 방법으로 널리 알려져 있습니다. 하지만 제 경험상, 반복적 개발을 RIA 프로젝트에 적용하고자 할 때엔 추가적으로 고려해야하는 부분이 있는 것 같습니다. 바로 디자인인데요, 기획이나 개발 파트의 경우 반복적인 작업이 비교적 용이한데, 디자인의 경우 반복(iteration)이 아닌 재작업(rework)을 하게 되는 경우가 많은 것 같았습니다. 예를 들어 개발 파트에서는 리팩토링이나 테스트 자동화 등과 같은 실천법을 통해 반복적 개발을 효과적으로 수행할 수 있는데, 디자인 파트의 경우 반복적 작업의 효율을 높이기 위한 좋은 실천법이 충분히 개발되지 못한 것 같아요. 스프링노트 팀에서는 반복적 프로세스를 유지하기 위해 디자인 파트에서 "재작업"이라는 부담(혹은 희생)을 지고 가고 있는 상황입니다.

어... 맺음말은 없습니다. ㅋㅋ