태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'facebook'에 해당되는 글 3건

  1. 2016.03.30 페이스북 새 공감(좋아요) 버튼에 대한 개인적인 느낌 (2) by 이 재용
  2. 2012.03.31 [UI 디테일] SNS의 댓글 네비게이션 구조를 어떻게 설계하는것이 좋을까? (10) by 위승용 (uxdragon)
  3. 2011.08.25 왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다 by 이 재용
2016.03.30 07:50

페이스북 새 공감(좋아요) 버튼에 대한 개인적인 느낌

페이스북이 '좋아요' 단일 버튼에서, 총 6가지 감정으로 바꿨다.


페이스북에서는 이것들을 공식적으로 '공감'(Reactions)이라고 부르는데, 영어로는 emoji, response button이라고도 하고, 한국어로는 이모티콘, 반응 아이콘, 공감 아이콘이라고 하기도 한다. 이 프로젝트는 1년 전쯤 마크 저커버그가 사람들을 불러 모아 지시했다고 한다. '좋아요'버튼이 생기자마자부터 듣기 시작한 사용자들의 요구 사항이었으니 얼마나 오래 참아 왔던가. 물론 사람들이 가장 강력하게 원했던 것은 '싫어요' 버튼이었지만, 그건 들어가지 않았다.

http://vip.mk.co.kr/news/view/21/21/2509009.html


프로젝트를 총괄한 사람은 Julie Zhuo라는데, 수백가지 감정 중 단순하게 몇 개의 감정으로 추리기 위해 영화 인사이드 아웃의 자문이기도 했던 Dacher Keltner UC 버클리 교수의 도움을 받았다고 한다. 이들은 대략 필요한 감정을 20-25개 정도로 줄였고, 그 중에서 사용자들이 가장 많이 '표현'하는 감정들을 기존 사용자 댓글 등에서 추출하여 최종 7개를 선택했다. 이렇게 원래 7가지로 실험을 하다가 최종 출시에서는 yay가 빠지고 6개로 나오게 되었는데, yay는 다른 것보다 현저하게 사용이 떨어졌다고 한다.


그 다음 문제는 어떻게 나타나게 할 것인가?인데, UX 디자이너라면 누구나 고민할 만한 문제에 적절한 선택을 한 것 같다. 아래 영문 와이어드 기사는 꼭 읽어 볼 만 하다.

http://www.wired.com/2016/02/facebook-reactions-totally-redesigned-like-button/



개인적으로는 페이스북 최고의 히트 UX인 '좋아요' 단일 버튼으로 계속 유지하길 바랬지만, 늘릴 수 밖에 없는 시점이라는 것도 이해는 간다. 사실 '좋아요'의 강력함은, '좋아요'에 있는 것이 아니라, '좋아요 하나 밖에 없음'에 있기 때문이다.


1.

그런데, 일단 '딱 하나'를 포기한 것은 이해가 되지만, 나머지 부분은 이해가 안 되는 것이 많다. 굉장히 고민을 많이 해서 고른 6개일테지만, 썩 마음에 들지 않는다. (지극히 한국적인 사고일 것 같긴 하지만) 좋아요 말고 내게 제일 필요한 건 '공감해요' 버튼이었다. 무언가 글을 쓴 사람을 위로하고 싶은데, 글로 하기는 애매하지만, 그 사람의 감정에 공감하고 (그것이 즐겁든, 슬프든, 화나든) 지지하고 싶은 때가 제일 많은데, 그 버튼이 없어서 너무 아쉽다. 물론, 상대가 즐거워 하면 나도 '즐거워요'를 누를 순 있지만... 그건 좀 다른 거 아닐까?


친구의 아는 사람이 죽어서 슬프다고 한다. 나는 '슬퍼요'를 누를 수는 없다. 나는 슬프지 않기 때문이다. 하지만 내가 아끼는 친구가 슬프다니, 그에게 공감하고, 위로하고 싶은데, 내게 제일 필요한 그 버튼이 없다.


내가 디자이너라면, '공감해요'를 우선 추가했을 것 같다. 기쁜 일에는 '좋아요'를 공감으로 쓸 수 있지만, 슬프거나 화나는 일에 '좋아요'를 공감으로 누르기는 매우... 꺼려진다. 내가 '좋아요'에 답답함을 느끼는 유일한 순간이다. 결국 친구가 슬프다는데, 친구 아이가 아프다는데, 아무도.. '좋아요'를 눌러주지 않는 현상이 생기게 되기 때문이다. 마치 반응이 매우 싸늘한 느낌인데, 실은 대부분의 사람들이 뭔가 하고 싶지만 '좋아요'를 누르는 건 너무 이상하기 때문에 안 누르는 것이니까.


물론 개인적으로 '좋아요'와 '공감해요' 버튼 외에 다른 것들을 넣는 것은 싫지만, 디자이너로서는 어쨌든 결국 다른 감정들도 넣을 수 밖에 없었을 것 같다. 어차피 1개가 아니라면... 2개나 6개나 같기 때문이기도 하고.


2.

두 번째로, 왜 거기에 언어적 설명을 붙였을까? 그냥 이모티콘만 남겨두면 되지 않을까? '좋아요'가 있긴 하지만, 글자로 설명을 다는 순간 다양하게 해석하고 활용할 여지를 없애 버리게된다. 보도 자료에는 '좋아요-사랑해요-하하-와우-슬퍼요-화나요'라고 나와있는데, 지금 작동해 보면 '좋아요-최고예요-웃겨요-멋져요-슬퍼요-화나요'로 되어 있는 걸 보니, 아마 테스트를 계속 하면서 바꿔가고 있는 것 같기는 한데, 하트면 하트 자체로 족하지 '사랑해요'나 '최고예요'나 없는 것이 제일 낫지 않을까?


그래도 우리 말에는 각 단어들의 형태를 맞추었는데 (보도 자료의 경우에는 안 맞는다) 영문의 경우, 단어가 서로 문법적으로 안 맞는 비난도 있는 모양이다. (어떤 건 형용사, 어떤 건 감탄사, 어떤 건 동사나 명사 등) 


디자인팀이 이런 저런 사실을 모르거나 놓쳤을 것 같진 않고, 아마 충분히 고려하여 일부러 넣은 것 같은데, 이렇게 결정하게 된 근거 데이터나, 논리적 이유가 궁금하다.


3. 

그래도 '싫어요'를 넣지 않은 것은 정말 잘한 결정이라고 생각한다. 사용자가 가장 많이 요구하는 거였지만, UX가 반드시 사용자가 원하는 걸 들어주는 것이 정답은 아니라는 걸 보여주는 가장 좋은 사례가 되지 않을까 한다. 부정적인 반응은 페이스북을 더 황폐화 시켰을 것 같다.


4. 

나타나는 방식에 있어서도 6개가 동시에 나타나지 않는 점이 마음에 든다. 우선 매우 보기 싫었을 것이고, 혼란도 유발했을 것이다. 지금처럼 롤오버(마우스)나 롱프레스(터치)에 의해 나타나게 한다면, 사람들이 익숙해지는데 시간은 조금 걸려도 큰 반발없이 부드럽게 수용될 수 있을 것 같다.



물론 굉장히 많이 고민했을테니 외부에서는 모르는 많은 이유들이 있기 때문에 함부로 말하긴 그렇지만, 개인적으로 아쉬운 것을 표현해 보고 싶었다. 다만, 영어 문화권 사람들은 어떻게 생각하는지 정말 궁금한데 아직은 별다른 반응이 없다.


[참고##UI 디테일##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2012.03.31 22:04

[UI 디테일] SNS의 댓글 네비게이션 구조를 어떻게 설계하는것이 좋을까?

SNS 관련 프로젝트를 통해 댓글 네비게이션 구조를 어떻게 설계하면 좋을지에 대해 고민할 시간이 있었습니다. 본 블로깅을 통해 그러한 고민을 정리하고 공유하도록 하겠습니다.


1. SNS에서 최근 쓴 댓글은 위쪽에 보여져야 할까? 아래 쪽에 보여져야 할까?

SNS 댓글 UI 설계 시 가장 고민했던 부분이 바로 이 점 이었습니다. 당시로서는 판단의 근거가 없었기 때문에 타 SNS 들이 어떻게 UI를 설계하고 있는지 벤치마킹을 했습니다. 하지만 벤치마킹으로는 고민의 결과밖에 확인 할 수 밖에 없기 때문에 왜 이렇게 UI가 설계되었는지에 대해서는 별도의 고민을 해야 했습니다. 동료들과 대화하던 차에 SNS형 구조에서 댓글은 '대화의 흐름(히스토리)'이 중요하다는 사실을 알 수 있었습니다. 또한 대화의 흐름(히스토리)이 중요하기 때문에 위에서부터 아래로 댓글을 보는것이 자연스럽다고 판단하였습니다.

결과적으로 최근에 쓴 댓글은 아래 보여지게 설계하였습니다.


2. SNS에서 댓글 더보기 버튼은 댓글내용 위에 있어야 할까? 아래 있어야 할까?

SNS에서 댓글은 댓글의 흐름에 따라 보여지나, 댓글의 수가 많아질 경우 최근에 쓴 댓글들을 우선순위로 노출시켜야 합니다. 이 때 보통 UI 설계 시 댓글 더보기 버튼을 넣어야 합니다. 이 때 댓글 더보기 버튼을 댓글 내용 위에 넣어야 할지, 댓글 내용 아래 넣어야 할지 고민이 되었습니다. 이때도 타 SNS들이 어떻게 UI를 설계하고 있는지 벤치마킹을 했습니다. Facebook과 C로그는 댓글의 위에 댓글 더보기 버튼을 노출하였습니다. 그리고 Me2day는 댓글 아래 댓글 페이징 UI를 제공했습니다. 댓글 더보기 버튼을 아래쪽에 넣을 경우에는 대화의 흐름을 방해할 수 있다는 판단하에 댓글 더보기 버튼을 상단에 노출하였습니다.

결과적으로 댓글의 위에 댓글 더보기 버튼을 제공하였습니다.

['Facebook'의 댓글 더보기 방식]

['Facebook'에서 댓글을 볼때의 시선의 흐름]


Me2day의 댓글 페이징 UI도 신선하기는 했고, 고민의 흔적이 느껴지는 UI였습니다. 최근 글을 보려고 스크롤을 아래로 내린 상태에서 바로 이전 페이지, 다음 페이지로 이동할 수 있는 버튼이 있어서 다음 태스크로의 이동이 원활하게 이루어졌습니다. 다만 이전 댓글 버튼을 눌렀을 경우 위치가 고정이 되어 결국에는 스크롤을 위로 올린다음 다시 내려야하는 상황이 발생하게 되는 문제가 있었습니다.

['Me2day'의 댓글 더보기 방식]

['Me2day'에서 댓글을 볼때의 시선의 흐름]


3. 그래서, 타사 SNS들은 잘 하고 있는걸까?

2012년 3월 기준으로 Facebook, Me2day, C로그, 요즘의 댓글 노출 순서, 댓글 입력필드 위치, 댓글 더보기 버튼 위치, 댓글 입력 버튼, 타임라인에 댓글이 바로 노출되는지에 대한 여부를 조사하였습니다.

조사 결과는 다음과 같습니다.

[타 SNS들의 댓글 네비게이션 및 요소 비교 차트]

['Facebook'의 댓글 네비게이션 구성 요소]

['Me2day'의 댓글 네비게이션 구성 요소]

['C로그'의 댓글 네비게이션 구성 요소]

['요즘'의 댓글 네비게이션 구성 요소]


다른 서비스와는 다르게 '요즘'이 최근 작성한 글이 위쪽에 보여지게 설계를 하고 있습니다. 최근 작성한 글이 위에 보여지기 때문에 댓글 입력필드와 댓글 더보기 버튼이 다른 서비스와는 역으로 설계되어 있는것을 알 수 있었습니다. 최근 작성한 글이 위에 보여지는 방식은 SNS의 댓글 방식보다는 게시판 글 방식에 좀 더 적합합니다.   

[게시판 글 방식 : NHN 홈페이지 보도자료 게시판]


이전에도 기술하였듯이 Me2day의 댓글 더보기 방식은 기존의 더보기 버튼과는 다른 새로운 방식으로 문제를 해결 한 것으로 보입니다. 또한 늘 그렇듯 장점과 단점이 존재하는 UI였습니다.


다음 내용을 3가지 패턴으로 정리할 수 있습니다. (아래 이미지를 참고하세요.)

1. 댓글 더보기 버튼은 상단에 노출 + 시간순 정렬 : Facebook, C로그, Path 등

2. 댓글 더보기 버튼은 하단에 노출 + 시간 역순 정렬 : 요즘, 일반 게시판 등

3. 댓글 더보기 버튼을 하단에 노출(페이징 방식) + 시간순 정렬 : Me2day 등

[SNS의 댓글 네비게이션 구조 패턴]


글을 정리하며...


[SNS 댓글 및 게시판 네비게이션 구조 포지셔닝 맵]


결론적으로 댓글 네비게이션 구조를 시간순으로 정렬하고, 댓글 더보기 버튼을 상단으로 정렬하는것이 적합해 보입니다. 다음의 SNS '요즘'은 SNS의 댓글 네비게이션 구조라기 보다는 게시판형 게시글 구조와 같은 방식을 사용하고 있기 때문에 정렬을 다시 고민해봐야 될 것 같습니다.

또한 Facebook과 C로그 그리고 Path의 경우 댓글 더보기 버튼을 클릭하지 않아도 최근에 작성한 글 몇개를 보여주는 UI를 사용하고 있습니다. 이는 대화의 흐름을 유지하면서도 수시로 최신글을 확인하고자 하는 Active Persona를 반영한 UI로 보여집니다.

물론 이정도의 고민을 하지 않더라도 누구나 생각할 수 있는 당연한 고민이라고 생각합니다. 또한 타사 SNS에서도 이미 잘 하고 있습니다. 하지만 나중에 SNS UI 설계를 시작 한다고 했을 때에 단순히 타사 서비스를 베끼려고 하기 전에 왜 이런 UI를 설계했을지 설계자의 고민속으로 들어가서 진득하게 고민하는 시간을 가져보는것도 좋을 것 같구요.

물론 당연하게도 Persona에 입각한 Goal directed design이 우선적으로 이루어졌을 경우에는 이러한 결정이 손쉬울 수 있습니다. 하지만 프로젝트의 여건상 Persona 제작이 힘들다면 Rapid Persona를 만들어보는것을 우선 추천합니다. 그것마저 힘든 상황이라면 벤치마킹을 통해 정보를 수집하고, 수집된 정보를 토대로 한 UI 기획자의 직관과 고민에 의한 결정으로도 문제를 해결하는데 도움이 될 수 있을것으로 기대합니다.


감사합니다.


PS. 본 블로깅을 하는데 있어서 영감을 준 김금룡님, 내용이 정리될 수 있도록 명쾌한 의견주신 無異 님 감사합니다.


Reference site

Facebook - http://facebook.com

Me2day - http://me2day.net

C로그 - http://c.cyworld.com

요즘 - htttp://yozm.daum.net


[참고##UI 디테일##]


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 4 Comment 10
Ad Test...
2011.08.25 16:58

왜 어떤 가이드라인은 실패하는가? - 말보다 행동이 중요하다

그리 쉽지는 않지만, UI 디자이너에게 표준을 지키는 일은 중요하다. 특히 많은 사람들이 이미 따르는 표준이라면 그 중요성은 배가된다. 이해를 돕기 위하여 4회에 걸쳐서 Mac OS 표준, Windows OS 표준, 그리고 ISO(International Standard Organization) 표준의 역사에 대해서 알아보기로 한다.

1. 사용자의 80%만을 위해 디자인하라 - Apple Human Interface Guidelines의 역사
2. 마침내 혼란을 극복한 Windows7 - Windows User Experience Interaction Guidelines의 역사
3. 그들만의 리그, 우울한 ISO UI 표준 - ISO 13407 & ISO 9241의 역사
4. 왜 어떤 가이드라인은 실패하는가? – 말보다 행동이 중요하다


4. 왜 어떤 가이드라인은 실패하는가?

수많은 플랫폼, 회사, 어플리케이션들이 가이드라인을 만든다. 오늘도 누군가, 어디선가 가이드라인을 만들고 있을 것이다. 피엑스디도 가이드라인에 대해 업무 요청이 자주 들어온다. 그 때마다 피엑스디에서 늘 하는 말이 있다.

왜 어떤 가이드라인은 실패하는가?

가이드라인을 만드는 사람은 이 질문에 명확히 답을 가져야 한다. 그래야 성공적인 가이드라인을 만들 수 있다. 가이드라인의 중요성은 누구나 공감하지만, 성공하는 가이드라인은, 필자의 짐작에 1%도 안 될 것 같기 때문에, 그 1%안에 들려면 왜 수많은 가이드라인들이 모두 실패하는지를 알아야 한다.

우선 가이드라인에 어떤 말들이 들어가는지를 살펴보자 (가이드라인 전체를 비교할 수 없으므로 Design Principle에 해당하는 몇몇 키워드만으로 논의를 대체하고자 한다)


Jakob Nielsen 10 Huristics (1990-1994년)
Visibility of system status / Match between system and the real world / User control and freedom / Consistency and standards / Error prevention / Recognition rather than recall / Flexibility and efficiency of use / Aesthetic and minimalist design / Help users recognize, diagnose, and recover from errors / Help and documentation

Apple Mac OS (1987-2006년)
Metaphors, Mental Model(Familiarity, Simplicity, Availability, Discoverability), Explicit and Implied Actions, Direct Manipulation, See and Point, User Control, Feedback and Communication, Consistency, WYSIWYG, Forgiveness, Perceived Stability, Aesthetic Integrity

Windows 2000 (1992-2007년)
User in Control, Directness, Consistency, Forgiveness, Feedback, Aesthetics, Simplicity

SKT NATE UI Requirement Ver 1.0 (2003-2004)
철학(Clear, Speedy, Attractive), 원칙(Visibility, Simplicity, Consistency, Familiarity, Efficiency, Prioritization, User in Control, Feedback, Error, Affordance, Persnoalization, Fun)

KTF 표준 UI 규격 v2.0 (2005)
철학(Fun UI, Easy UI, Happy UI), 원칙(Intuitiveness, Consistency, Efficiency, Attractiveness)

Google (연도미상-)
useful, fast, simple, engaging, innovative, universal, profitable, beautiful, trustworthy, and personable.

Facebook (2009년-)
Universal, Human, Clean, Consistent, Useful, Fast, Transparent

네이버 UX의 9가지 원칙 (2013, UX World 발표, 출처: UX 디자인 팀블로그)
1. 사용자와 비즈니스를 이해한 UX디자인
2. 주요 기능과 정보의 우선순위가 정리된 UX디자인 (Prioritization)
3. 네러티브가 잘 구성된 UX디자인 (Storytelling)
4. 인터랙션이 잘 설계된 UX디자인 (Interaction)
5. 사용자 무의식 반응을 리드하는 UX디자인 (Intuitive)
6. 정보인지를 빠르게 도와주는 UX디자인 (Clear)
7. 디바이스의 특징과 테크놀러지가 잘 활용된 UX디자인
8. 그래픽 디테일이 아름다운 UX디자인 (Beautiful)
9. 브랜드에 좋은 영향을 주는 UX디자인 (Brand)
위의 과정에서 소소한 혁신의 지속성을 가지는 디자인.

현대카드 (2014, UX World 발표)
현대카드의 UX 철학 : Remarkable but Extremely Kind
Clear, Useful, Interaction, Storytelling, Simple, Consistent, Brand Expression + More Creatitvity




Shneiderman's "Golden Rules"
usability.gov's "Research-Based Web Design & Usability Guidelines"
UserFocus 247 web usability guidelines
기타 많은 가이드라인들(A huge list of Style Guides and UI Guidelines하나더,또하나더)


보면 아시다시피, 제이콥 닐슨의 기념비적인 휴리스틱 10가지 원칙 중심으로, 사실 모두 비슷비슷한 원칙들의 순서 바꾸기에 불과하다. 물론 직접 작성한 사람들은 하나 하나 공들여 골랐을 것이고, 오랜 시간 고민하여 순서를 정했을 것이다. 애플이나 몇몇 회사의 경우 오랜 시간 동안 자신들이 중요하다고 생각하는 것을 다듬어왔음도 알 수 있다. 그러나 나머지 모든 회사들의 원칙들과 비교해 볼 때, 애플이 무언가 잘 하고 있다면, 그것은 디자인 원칙(철학)을 잘 다듬어왔기 때문에 잘하고 있다고 보기는 어렵다는 것을 쉽게 알 수 있다.

그럼에도 애플에서 나온 제품들은, 그리고 그 플랫폼 위에서 개발되어 나오는 제품들은 모두 이 뛰어난 철학들을 공유한 것처럼 보이고, 대부분의 회사들이나 플랫폼은 그렇지 않은 것처럼 보이는 이유는 무엇일까? 왜, 어떤 가이드라인은 성공하는 것처럼 보이고, 어떤 가이드라인은 실패하는 것처럼 보일까?

UIE의 Jared M. Spool은 올해(2011) 5월에 자신의 글에서 필자가 지적했던 것처럼 대부분의 가이드라인이 비슷비슷하다는 것을 지적하면서, 이와는 차별된 가이드라인으로 Windows 7 가이드라인을 예로 들었다. Windows 7 가이드라인에 대해서는 필자도 몇 차례 글을 통하여 훌륭하다고 지적한 바 있는데,

Windows 7 (2010년, 원문)
1. Reduce Concepts to Increase Confidence
2. Small Thinks Matter, Good and Bad
3. Delight
4. Solve Distractions, not Discoveratbility
5. Time Matters; Build for People on the Go
6. Value the Full Lifecycle of the Experience
7. Be Great at "Look" and "Do"

그러면서 Spool은 위대한 가이드라인이 되기 위한 6개의 원칙을 제시한다.
1. 연구로부터 바로 추출된 것인가?
2. 대부분의 경우에 ‘아니다’라는 판단을 내릴 수 있는 근거를 제시하는가?
3. 경쟁자로부터 차별화 시킬 수 있는 원칙인가?
4. 나중에 반대로도 할 수 있는 것인가?
5. 이번 프로젝트에 근거해 평가할 수 있는 것인가?
6. 계속 의미를 검증하고 있는가?

Spool은 일반 사람들이 갖고 있는 ‘원칙(혹은 철학)’에 대해 갖고 있는 고정관념 – 영구 불변의 변치 않는 원칙 – 과 비교했을 때 이런 위의 원칙들이 언듯 보기에 직관에 반하는 것처럼 보이지만 실제로 이러한 것들이 위대한 디자인 가이드라인을 만든다고 주장한다.

Spool의 말에 전적으로 동의한다. 특히 2004년에서 2006년에 걸쳐 진행된 한국의 경쟁 두 이동통신사(SKT와 KTF)의 UI 가이드라인을 보면서, 어쩜 두 회사가 만드는 과정에서부터 결과까지 쌍둥이처럼 똑같을까?하는 생각을 하였던 필자로서는 더욱 크게 동감할 수 밖에 없다. 두 회사의 철학은 거의 비슷했다. 사실 두 회사만 비슷한 것이 아니라, 세상 모든 나머지 가이드라인들과 비슷했다. 어느 회사인들 Fun 하지 않은 걸 원할 것이며, 누군들 쓰기 어려운 걸 원할 것인가? 이런 식의 하나마나한 말 잔치 철학들은, 가이드라인을 읽는 독자들이 ‘무시’하기 쉬웠다. 경쟁사와 구별할 수 있는 철학도 없었지만, 그렇다고 틀린 말도 없었다.

구글이나 페이스북처럼 그리고 많은 회사들의 경우 이런 비슷비슷한 원칙이 나오기 때문에 결국 철학을 무시하게 되니, 남는 건 뒷 부분의 픽셀 단위 가이드라인과 지정된 칼라 밖에 없다. 이렇게 남은 가이드라인은 개별 어플리케이션을 디자인하는 사람들의 창의력을 막고 천편일률의 통일성만 강조된 결과를 남긴다. 그나마 잘 지켜진다면 말이다. 절대 변할 수 없고, 절대 틀릴 수 없는 철학들은 결국 절대 사용될 수 없는 철학인 것이다.

하지만, 이런 철학으로도 잘 하는 예외적인 회사가 있으니, 반드시 또 이 철학이 틀렸다고 말할 수는 없다. 그렇다면 Spool의 지적은 맞긴 하지만 부족한 지적이다.

왜, 어떤 가이드라인은 성공하고 어떤 가이드라인은 실패하는 걸까?

필자는 그것이 ‘가이드라인’이 갖는 권위 – 절차적 정당성에 근거한 영향력에 달려 있다고 생각한다.

대개의 가이드라인은 이렇게 만들어진다.
우선 자신의 제품이 중구난방임을 깨달은 UI 전담팀의 누군가가, 외부의 가이드라인을 수집한다. 모든 가이드라인을 수집한 다음에 자기 마음에 드는 것을 고르고 순서를 바꾼다. 그런 다음 힘이 있는 임원을 설득한다. 운 좋게 임원이 설득되면, 찍어 누른다. 지금까지 잘 하고 있던 현업 부서는 반발한다. 임원의 권력의 크기에 따라, 따라하는 시늉을 하든지, 아니면 진짜로 조금 따라하든지 한다. 가이드라인의 힘이 커지게되면 제품은 천편일률이 되고 문제를 깨닫는다. 조금씩 예외가 많아지다가, 해당 임원이 교체되면서 가이드라인도 사라진다.

더욱이 한국의 가이드라인은 대개 이렇게 만들어진다. 전담팀 누군가가 스스로 만들면 권위가 생기지 않을 것이므로 대학교 교수님께 맡긴다. 그러면 대학교 석사 1-2년차들 (즉 방금 학부 졸업한 학생들)이 자료를 수집하여 초안을 만들고, 박사 과정이 다듬고, 교수님이 검증한다 (사실 직접 실무를 안 해 보긴 모든 구성원이 비슷하다). 이렇게 실무 경력 합계 0년이 만들어낸 가이드라인을, 학위는 없지만 실무에서 잔뼈가 굵은 사람들이 따라야한다. 당연히 반발하지만, 역시 위에서(중앙부서에서, 그룹 본부에서) 찍어 누른다. 그 결과는 비슷하다.

이렇게 만들어진 가이드라인의 품질이 좋을 리도 없지만, 설령 품질이 좋다고 하더라도 구성원들이 그것을 충분히 이해하고 따라하려는 노력을 하기에는 권위가 없다. 권력에 의해 강요한다면 결국 그것은 시늉을 낳게 되고, 기계적인 적용 방법을 찾게 되고, 창의력은 점점 사라지게 되는 것이다.

그렇다면 성공하는, 즉 영향력있는 가이드라인은 어떻게 만들어야할까?

첫 번째는 구성원들의 합의에 의해 만들어야 한다는 점이다.
Nokia가 어떻게 가이드라인을 만들었는지 보자.

표준 문서를 만드는 순간 창의성은 사라진다. 그 사실을 알기 때문에 우리는 가능하면 최대한 표준 문서 만들기를 꺼렸다. 문서 대신, 단지 그런 방향은 아니라고 관리자들이 구두로 말하다 보니, 그것을 관리자 개인의 성향으로 모는 일도 생겼다. 마침내 같은 기본적인 질문을 반복해서 대답하고 있다고 느끼게 되자, 두 명의 시니어 디자이너가 원칙을 모아 명확하게 정리하기 시작했다. (Mobile Usability, 150p, 2003년 영문판 번역)

처음부터 문서를 만드는 것이 아니라, 디자인을 하는 사람들이 계속되는 협업과 토론을 통해 철학을 형성, 공유하고, 새로 들어온 신입들에게 같은 질문에 대한 같은 대답을 반복하다가 효율을 높이기 위해 표준 문서를 만들었다는 내용이다.

철학은 외부에서 가져올 수 없다.
위의 구글 디자인 원칙들은 허접하지만, 구글 철학을 한 번 보면, 몇 몇 개의 것들은 절대 다른 회사가 갖고 있지 못 하는 구글만의 문화와 철학이 느껴져서, 그것에 따르면 오히려 디자인 원칙들보다 더 제품의 전략과 인터페이스를 설계하는데 도움이 되지 않을까 생각한다. 창업자를 중심으로 창업 과정의 사람들이 함께 공유하고, 또 실천한 문화와 철학을 정리한 것이기에, 누구도 쉽게 적용할 수 있다. 또 어느 회사에게 맞는 것이 아니라, 구글만이 할 수 있는 것들이 듬뿍 담겨있다.

두 번째는 실패 사례로부터 출발하는 경우이다.
윈도즈 7의 원칙들을 살펴보면, 그간 무의미하고 추상적인 원칙들이 아무런 도움을 주지 않는다는 것과, 비스타의 처참한 실패로부터 배운 것들을 잘 정리하고 있다. 오랫동안 윈도우 사용자들을 리서치하고, 그에 따라 자신들에게 꼭 필요한 원칙들을 모으고, 첫 번째로 윈도우 7의 디자인을 하는데 적용을 한 것이다.
기존의 원칙들의 정신을 살린 것이라 하더라도, 자신들의 실패를 극복하기 위해 좀 더 정밀하게 좁혀졌고, 명확하게 설명이 되기 때문에 다른 사람들이 읽었을 때 무엇을 해야할지, 무엇을 하지 말아야할지가 분명하다. 따라서 이렇게 만들어진 원칙들은 윈도우 7만의 특징을 잘 설명하고 있다.

세 번째는 성공 사례로부터 출발하는 경우이다.
사람들은 리더의 말이 아니라 행동을 따라 배운다. 아이들은 부모의 말보다는 행동을 따라하고, 팀원은 팀장의 행동을 판단 기준으로 삼으며, 협력 파트너들은 그 회사의 가이드라인이 아니라 출시된 제품을 따라 만든다.

아무리 가이드라인에 ‘Simple’이라고 적어도, 나오는 제품들이 모두 복잡하다면 그건 아무런 의미없는 내용이 되고 마는 것이다. 경영자가 아무리 디자인이 중요하다, 소프트웨어가 중요하다고 떠들어도, 코스트(제조원가)에 밀려 디자인이 희생되고, 승진에서 재무 출신이 임원이 되면 그 회사는 디자인이나 소프트웨어를 중요하게 생각하지 않는 것이나 마찬가지다.

따라서 새로운 조직에서 가이드라인을 만들려고 한다면, 반드시 새로운 프로젝트(결과물)와 함께 만들어야 한다. 그 과정에서 서로 토론하고, 문화를 형성하고, 결과물에 적용하고 그 결과물을 성공시켜야 한다. 결과물이 성공하면, 사내외의 다른 사람들이 따라 하려할 것이고, 사람들이 따라하는 부분을 가이드라인으로 만들면 된다. 그것이 진정한 영향력이다.

정리하면,
1. 직접 쓸 것. 함께 쓸 것. 문화와 철학을 만들 것. (남의 도움은 받을 수 있으나, 남이 만들어 줄 수 없다)
2. 학부 막 졸업한 석사과정에게 맡기지 말 것. 출시된 상품의 화면 설계서를 백 번 이상 그려 본 사람에게 맡길 것.(자기 손으로 같은 버튼을 수백번 그렸다 지웠다 해 본 사람이 아니면 원칙을 만들 수 없다)
3. 성공 사례를 먼저 만들고 전파할 것. 성공으로부터 영향력을 만들 것. (권력에 의해 배포된 가이드라인은 권력과 함께 사라진다)

이것 저것 생각하기 싫다면? 피엑스디에 맡기면 된다. :)

[참고##가이드라인##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...