by
Dec 03. 2023
#26 웬만하면 가벼울수록 좋다
2023년 48주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/74
다음 회고 ☞ https://brunch.co.kr/@327roy/76
노트
#1 웬만하면 가벼울수록 좋다
#힉의법칙 #UX #인지심리 #기획
'웬만하면 화면에서 제공하는 정보가 적어질수록 좋다.'
특히 모바일 기획을 하면서 더 많이 느끼는 것이다. 여기서 제공하는 정보가 적다는 것은 하나의 화면 내에 각자 다른 목적을 가진 기능이 적고, 화면을 구성하고 있는 정보의 목적이 비슷한 것들로 모이는 것을 의미한다.
한 화면에서 기능이 여러 개 붙게 되는 경우 사용자가 선택할 수 있는 행동들이 많아진다. 이런 ‘유저 스토리’가 많아짐에 따라 발생하는 문제점은 당연히 ‘화면에서 제공해야 하는 정보가 많아진다'는 것이다. 이는 곧 '사용자가 인지해야 하는 것들이 많아진다'는 것으로도 말할 수 있다.
예를 들어, 간단하게 기록을 남기는 모바일 서비스에 ‘사진 업로드 기능’을 추가한다고 생각해 보자. 이때 우리는 단순하게 ‘사진 업로드’만 구현하면 될까? 그렇지 않다. 사진 업로드를 하려면 기본적으로 사진 조회, 삭제부터 사진을 보여주는 방식, 정책 등 신경 써야 할 것이 많다.
1. 기능 이름
- 사진 업로드
2. 함께 고려되어야 하는 기능
- 사진 조회, 사진 삭제
3. 함께 고려되어야 하는 정책
- 사진을 조회한다면 컨테이너에 사진을 Height, Width 중 무엇에 맞출 것인지
- 사진 확대 방법(핀치 인? 터치?)
- 업로드 가능한 최대 장수
- 업로드 가능한 사진의 용량
- 업로드 가능한 사진의 확장자
*사진 조회 방식, 사진 확대 방법의 경우 보편적으로 디자이너가 정해주는 편이다.
이처럼 우리가 하나의 기능이라고 생각한 것은 사실 작은 기능들의 집합인 것이고, 이 때문에 우리가 단순히 기능 하나라고 생각하는 것에서 여러 개의 유저 스토리가 도출될 수 있다.
만약에 이 기능이 존재하는 화면 속에 (뜬금없지만) 댓글 기능, 공유 기능 등이 존재다고 가정해 보자. 우리는 사용자가 이 화면에서 사진도 업로드하고, 댓글도 남기면서 남들과 공유를 하기도 원한다. 하지만 사용자는 이 화면에 진입해서 자신이 무엇을 해야 하는지 즉각 알아차릴 수 있을까?
화면에서 어떤 주목적을 설정하는지, 각 기능들의 UI상 강세를 어떻게 줄 것인지에 따라 알아차리기에 보다 편하게 만들 수는 있다. 하지만 화면을 사용하는 입장에서 생각해 보면, 좁은 화면 속에 할 수 있는 선택지가 너무 많아지는 것인 만큼 즉각 알아차리는 것은 힘들다고 생각할 수 있다.
이처럼 하나의 화면 속에서 취할 수 있는 선택지가 많은 것은 제품의 복잡성을 높이며, 이로 인해 사용자가 인지하기 위한 비용을 증가시킬 수 있다. (힉의 법칙)
힉의 법칙을 설명하는 그래프 ⓒ https://kusim.tistory.com/그래서 화면은 항상 가벼워지면 좋다고 생각한다.
우리는 사용자의 목표를 정확하게 설정하고, 이를 방해하는 요소를 줄이거나 없애는 것을 궁극적인 목표로 삼아야 한다.
그리고 우리는 사용자가 진입해서 보는 화면에서 사용자가 우리가 의도한 가치를 명확하고 깔끔한 UXI를 통해 제공할 수 있어야 한다.
위의 내용과 비슷한 예시를 토스에서 진행한 아티클을 통해서도 확인할 수 있다. 사람은 항상 인지를 위한 수고를 하기 때문에, 글, 대화, 화면 등 사람과 접하는 것들이 간단하고 명료할수록 각광받는 것이 아닐까.
https://toss.tech/article/bad-reference-uses?fbclid
#2 소통의 기술: 좋은 대화란
#소통 #기술 #대화
UX 라이팅과 관련된 아티클을 읽고 학습하다 보면 글을 쓰는 것 또한 (문자로) 남들과 대화하는 과정이기 때문에, 좋은 대화, 좋은 소통을 하는 방법에 대한 얘기를 자주 볼 수 있다.
이때 많은 책들이 항상 좋은 대화의 원칙으로 말하는 것은 ‘1) 적절한 시기에 2) 필요한 말을 명확하고, 3) 간결하게 하는 것’이다. 나는 이 세 조건을 아래처럼 풀어서 설명하곤 한다.
1. ‘적절한 시기’는 청자가 그 대답을 듣기를 원할 때(필요할 때)다.
- 아무리 좋은 피드백이라도 청자가 수용할 준비가 되어 있지 않다면 그것은 잔소리로 남을 뿐이다.
- 그래서 많은 피드백이 수동으로 이루어지고는 한다(청자의 요청 → 화자의 대답).
- 이 때문에 리더들을 위한 많은 책에서는 좋은 대화를 위해 ‘능동적인 피드백’을 강조하곤 한다.
2. ‘필요한 말을 명확하고, 간결하게 한다는 것’은 청자가 원하는 대답(필요한 대답)이다.
- 청자의 배경에 따라서 부연설명이 필요할 수도 있고, 필요 없을 수도 있다. 하지만 너무 많은 부연설명, 예시는 청자가 대화를 인지하는 것을 방해하기 때문에 비효율적일 수 있다.
- 우리들이 ‘두괄식으로 말하자’라는 말을 달고 지내는 이유도 여기에서 출발한다. 미괄식, 두괄식 둘 중 뭐가 더 좋은 방식이라고 말할 수는 없지만, 적시에 좋은 방법으로 대화하는 기술이 필요하다.
물론 나도 언제나 좋은 대화를 하고 있다고 말할 수는 없지만, 적어도 위의 문장을 기준으로 삼아서 말하려고 노력하는 중이다.
#3 먼저 채워져야 하는 것은 맥락이다.
#맥락 #기획 #의사소통
요즘에는 특히 더 ‘맥락’을 중요하게 생각한다.
(너무 자주 언급하는 듯)
여기서 나는 맥락을 ‘배경’, ‘히스토리’, ‘원인’, ‘이유’ 등을 혼용해서 사용할 때가 종종 있는데, 이를 관통하는 의미는 ‘배경’에 제일 가까울 듯하다.
우선 맥락의 사전적 의미는 ‘연달아 맥脈’에 ‘이을 락絡’을 사용한다. 이를 네이버 사전에서는 ‘사건과 물건 따위가 서로 관련되어 이어져 있는 관계’라고 말한다. 맥락은 대화를 이어나가거나, 흐름을 이어나가는 데 있어서 꼭 필요하다.
이때 맥락이 채워져야 하는 이유는 분명하다. 나 혹은 남이 그 상황이나 대화를 더 잘 인지하기 위함이다. 이는 우리가 평상시에 누군가와 대화를 하는 것에서, 혹은 어떠한 제도나 절차에 대해서 내가 받아들이기 위해서 필요하다. 맥락을 알아야지 타인의 의도나 발생한 현상을 정확하게 인지하고, 나아가서 타인과의 관계 속에서 공감을 보다 쉽게 끌어낼 수 있기 때문이다.
나는 이를 협업 시 관계자들의 동기를 부여하는 수단으로도 활용하려고 노력 중이다. 일상적인 대화를 예시로 말하면, “우리는 고객이 불편함을 느끼는 지점을 OOO으로 진단했어요. 그래서 우리는 이 기능을 개발할 필요가 있어요.”를 개발자에게 전달하는 것이 있다.
이때 맥락의 유형은 크게 두 가지로 나눌 수 있다.
1. 상황 맥락
- 담화나 글, 상황을 파악하는데 관련한 요인을 의미한다.
- 화자와 청자, 시간과 장소, 의도와 목적 등 그 상황을 구성하고 있는 요소들이라고 말할 수 있다.
- 텍스트보다 대화가 상황을 이해하기 쉽고, 화상 미팅보다 대면 미팅이 이해하기 편한 이유는 맥락을 구성하고 있는 요소들(비언어적 대화부터 현재를 구성하고 있는 상황)을 잘 확인할 수 있기 때문이다.
2. 사회/문화적 맥락
- 특정한 공동체에서 사회적, 문화적으로 시간이 지나며 만들어진 맥락을 의미한다.
- 우리나라가 “괜찮아”와 같은 말을 다양한 의미로 사용하는 것을 이 개념으로 설명할 수 있다.
- 자기 조직화 속에서 발생한 일종의 규칙들이라고 말할 수도 있겠다.
기획자로 지내며 다양한 사람들과 관계를 만들고, 커뮤니케이션을 하며 이에 대한 힘을 알고, 이로 인해 맥락의 중요성을 더 체감하고 있는 요즘이다.
#4 이번 주의 아티클:
레드버스백맨, 알라딘
#아티클 #레드버스백맨
이번 주에 읽은 아티클 중에 레드버스백맨님의 글이 기억에 남는다. 인상 깊었던 내용은 1) 학습된 편리성과 2) 체류시간 지표에 대한 것.
1. 학습된 편리성
인간의 큰 특징 중 하나는 어떤 환경에서든 적응을 잘한다는 것이다. 이는 우리가 불편한 것을 느끼는 것에게도 통용된다. 처음 사용할 때는 불편했던 기능도 익숙해지면 너무나 편하게 사용하곤 한다. 나에게는 피그마, 노션이 그런 케이스다. 이것을 글에서는 '학습된 편리성'이라고 부른다.
그러면 불편함을 가장 잘 캐치할 수 있는 지점은 언제일까? 가장 익숙해지지 않았을 때, 즉, 그것을 처음 접했을 때 우리는 가장 불편함을 많이 느낄 수 있다. 그래서 나는 항상 제품을 새로 사용할 때의 감정과 생각을 기억하려고 한다.
기획자인 이상 제품을 이리 뜯어보고 저리 뜯어보게 되기 때문이다. 특히 직접 기획을 하는 중인 제품인 경우 다른 제품보다 빠르게 '내 자식 필터'가 씌워지게 되어, 이전만큼 냉정하게 바라보는 것이 힘들어지는 경험이 많다. 그래서 본인이 한 기획에 대해 항상 어느 정도의 의심을 유지하려고 한다.
사용할수록 익숙해지는 것은 대부분의 사람들이 경험하는데, 이를 통해 생각해 보면 제품 혹은 신규 기능에 대한 피드백이 적절한 시점은 제품 혹은 기능을 사용자가 사용한 후 비교적 최근일수록 그렇지 않을 때보다 정확할 수 있지 않을까? 그런 의미에서 현재 팀에서 만든 규칙인 '배포 일주일 뒤 사용성에 대한 인터뷰'는 충분히 시도해 볼만한 기준이라고 생각하고 있다.
2. 체류시간
온오프라인 제품을 운영할 때 중요한 지표 중 '체류시간'이 있다. 사용자가 제품의 사이클에서 우리가 정의한 사이클에 인입되어 이탈 혹은 특정 행동을 하기까지 걸린 시간을 의미한다.
글에서는 1) 체류시간을 따질 때 원하는 제품을 찾지 못해 헤매거나 배회하는 사람들이 얼마나 되는지 그 비율을 따져야 하는데 이를 '혼란 지수'라고 하며, 2) 실제로 10분 머무는 사람이 원하는 제품을 살펴보지 못하고 계속 헤맸다고 한다면 인지된 시간은 30분에 가까울 수 있다고 말한다. (아마 혼란지수를 어떠한 과정을 거쳐 '3'으로 도출한 듯.)
체류시간이 특히 중요하게 적용되는 사이클은 '우리가 중요하다고 판단한 지표(행동)'이 일어나기 직전까지의 시간일 것이라고 생각한다. 제품에 따라 체류시간이 적거나 많다고 꼭 좋은 것은 아닌 것을 인지하고, 나중에는 체류시간, 대기시간 등의 세션 지표를 활용한 개선을 해보고 싶다. 그전까지 개인정보보호 이슈가 어떻게 될진 모르겠지만.
https://www.redbusbagman.com/used0580/
#5 인스파이어드
#인스파이어드 #PM #기획자
인스파이어드