논리와 설득이 있는 디자인
텍스트 레이블이 필요한 이유
상대를 설득하는데 있어서 아리스토텔레스는 본인의 저서 수사학에서 3요소가 필요하다고 정의했다. 로고스, 파토스, 에토스다. 왠 라틴어인가 싶지만 사실 이들은 간단하다.
에토스는 명성, 신뢰감, 호감 등 메세지를 전달하는 사람에 대한 인격적인 측면이다. 예를 들어 부모가 하루에 담배 한갑씩 피는애연가라고 치자. 자녀들에게 '너만큼은 담배피지 말아라' 한다면 애가 귓등으로도 부모 말을 안듣는다는 것이다.
파토스는 공감, 경청 등으로 친밀감을 형성하거나 유머, 공포나 연민 등 감정을 자극해 마음을 움직이는 감정적 측면이다. '눈물로 호소'가 여기에 근거하는 얘기다.
로고스는 논리적인 근거나 데이터로 상대방의 결정을 정당화 시킬 수 있는 근거를 제공하는 논리적 측면이다. 허리디스크에 대해 의사가 얘기해주는 것과 물리치료사가 얘기해주는 것 중 신뢰가 가는 쪽은 어디일까? 당연히 의사가 얘기해주는 허리디스크가 더 잘 와닿을 것이다.
설득에서 로고스가 제일 중요할 것 같지만 로고스가 차지하는 비율은 10퍼센트란다. 왜냐하면 에토스가 제일 중요하고 제일 어렵기 때문이다. 아무리 논리정연하게 얘기를 해도 그 사람이 전직 사기꾼이라하면 그게 과연 설득적일까 하는 맥락이다.
그렇다면 디자인에서도 과연 설득하는 사람에 따라 컨펌이 잘 될까?
나는 정말 좋은 사람이고(아마도) 개발자와 꼬박꼬박 술도 같이 마시는 친밀한 사이이니까 내 시안은 개발자한테 충분히 먹혀들어가겠지? 라고 생각해도 되는걸까
이 텍스트 레이블을 꼭 넣어야해요?
나와같이 협업하는 앱개발자가 넌지시 물었다.
나는 단호하게 얘기했다. 꼭 넣어달라고...
그랬더니 카톡은 안넣는데 왜 넣어야하는지 모르겠단다.
텍스트 레이블은 이런걸 얘기한다
그런데 카톡에는 이런 텍스트 레이블이 없다.
카톡 네비게이션에는 텍스트 레이블이 없다. 이 사건의 원흉넣는게 더 친절한거에요. 했더니 누가 그랬냐고 따져물었다. 나는 당당하게 말했다.
제가 어디서 봤어요!
말하고 나서 내가 너무 한심했다. '그 어디가 구글의 머티리얼 디자인 가이드였는지 브런치였는지 블로그였는지 일일히 다 기억할순없잖아?' 이렇게 합리화를 하면서 그냥 지나갈까 하다가 멈췄다. 디자인이라는 것도 많은 경험과 테스트를 통해 데이터가 축적된 후 나온 논리적인 결과물이다. 디자이너도 이성적이고 논리적이어야 한다. 설득력과 논리가 없는 디자이너는 그만큼 힘을 잃을 수 밖에 없다. 마치 '너 저번에 치킨 먹었잖아?'라고 친구가 애기했을 때 '내가 언제? 몇날 며칠 몇시 몇분에?' 라고 얘기하는거랑 똑같다.
그래서 그 '어디서'를 찾기 위해 다시 고군분투 했다.
<어도비의 모바일 네비게이션의 기본 패턴 문서>에 보면 텍스트 레이블에 대해 '아이콘을 누르기 전에 해당 기능을 명확하게 파악할 수 있게 됩니다.' 라고 한다.
https://blogs.adobe.com/creativedialogue/design-ko/basic-patterns-of-mobile-navigation/
그리고 밑에 링크를 타고 가면 텍스트 레이블을 왜 사용해야하는지 더 자세히 나와있다
https://www.smashingmagazine.com/2016/10/icons-as-part-of-a-great-user-experience/
결론적으로 대부분의 아이콘은 표준화 되어있지 않기 때문에 아이콘의 기능을 명확하게 알려주는 텍스트 레이블이 필요하다. UserTesting은 레이블이 있는 아이콘과 레이블이없는 아이콘을 비교하여 테스트를 해단다.
사용자의 88 %는 레이블이 지정된 아이콘을 탭했을 때 발생하는 상황을 정확하게 예측할 수 있었다.
앱에 고유한 레이블이 없는 아이콘의 경우, 사용자는 34 % 만 올바르게 예측했다
이런 아이콘들한테는 정말 텍스트 레이블이 필요하겠다. 누가봐도 모르겠는데?대기업같은 경우엔 색상 하나하나, 선 하나하나에 명확한 의미를 부여하도록 훈련한다고 한다. '이건 왜 이렇게 했어?' '저건 왜 저렇게 했어?'의 질문에 제대로 답해야한다. 이래서 다들 '사수~ 사수' 노래를 부른다. 대기업이나 중견기업에선 교육기간도 상당해서 뭔가 제대로 배우는 것 같다는데 나같은 중소기업 인재들은 이렇게 '알아서' 지식을 습득해야하니 성장이 더딜 수 밖에 없다. 좋은 점은 내가 스스로 알아내니까 내가 선생님이고 기억이 오래남는다는 것.
예전 SI업체에 다닐 때는 개발자와 케이스 스타일 네이밍 때문에도 싸운적이 있었다.
그 개발자는 우리 팀 팀장을 겸하고 있었는데 어느 날 상의도 없이 디자이너들한테 단체 메신저를 통해서 클래스명을 케밥식으로 하라는 것이었다. 우리는 그전까지 스네이크식으로만 사용하고 있었기 때문에 당연히 반발할 수 밖에 없었다. 의논도 없는 일방적인 강요였다. 일방적인건 둘째치고 논리도 없었다. 나는 네이버 '널리'나 다음 '다룸'에선 스네이크식을 사용하니 우리도 스네이크식을 사용하는게 맞다고 주장했다.
개발자 주장도 만만치 않았다. 케이스 스타일은 딱히 표준이 없어서 기업이 정하는대로 쓰면 된다고 했다. 외국에선 케밥식이 더 보편화되어있다고 했다. 나도 질세라 커뮤니티에 질문도 올려보고 외국 사례도 찾아서 미친듯이 메신저로 관련 링크를 보냈다. 결론적으론 팀장 뜻대로 되었고 나는 '고집이 센 디자이너'가 되어버렸다. 그렇다고 논리없이 주장만 했다면 나는 '논리도 없이 고집만 센 디자이너'가 되었을 것이다.
IT는 협업이다. 내가 기획자도 되고 디자인에 개발까지 한다면 논리나 설득은 필요없다. 하지만 우리는 서로 협업해야 하고 보완해야하고 끊임없이 대화로 끌어가야 하기에 논리와 설득은 필수이다. 무턱대도 지시와 강요, 주장만 한다면 좋은 서비스를 이끌어내지 못한다. 그러기에 조금 더 전문지식을 쌓고 스킬을 올려 내 직무에 맞는 좋은 대화를 이끌어내야 한다. 우리는 1인 기업이 아닌 팀이라는 조직이기 때문이다.
