슬랙 본사에 placeholder 몇 개냐고 물어본 썰
이 글의 BGM으로는 아이브의 <After LIKE>를 권합니다.
두 번 세 번 피곤하게 자꾸 질문하지 마
내 장점이 뭔지 알아?
바로 솔직한 거야
- After LIKE 가사 中
요즘 2022년 한 해를 되돌아보는 글을 쓰고 있다.
그러다 올해 소소하지만 재밌었던 한 에피소드가 생각나서 따로 이 글을 적어본다.
사건의 발단
배너 제목을 입력하세요, 검색어 입력 등을 제치고 선정된 '배너 제목 입력'한동안 내가 하드코딩 되어 있던 여러 배너를 어드민화 하기 위해 배너 등록부터 수정, 노출 여부 및 기한 설정 등 다양한 기능의 정책을 세우고 있었다. 배너 검색 인풋창만 하더라도 세워야 할 정책이 한두 가지가 아니다.
- 최소 몇 글자부터 최대 몇 글자까지 등록 허용할지?
- 한글/영문/숫자/특문 중 어떤 것들을 등록 허용할지?
- 영문은 대소문자 구분할 것인지? 아님 둘 중 하나만 입력 허용할지?
- 만약 특문은 등록 허용하지 않는다면 입력 무시할 것인지? 혹은 재확인 alert를 띄울 것인지?
- 글자 수 카운트는 띄어쓰기 공백도 포함해서 처리할 것인지?
- 검색버튼 누르고 나면 인풋창 텍스트는 유지할 것인지? 혹은 placeholder로 원복 할 것인지?
- 인풋창 텍스트를 유지한다면 커서 위치는 첫 텍스트에 놓을지 또는 맨 마지막 텍스트에 놓을지?
- plalceholder는 한 개로 할지, 여러 개로 할지? 등등
여하튼 이번엔 placeholder 문구를 정했어야 했는데, 이게 참 별 것 아닌데 괜히 결정을 못하고 있었다.
참고로 내가 현 직장에 원래 UX Writer로 지원을 했었다. 회사의 권유로 프로덕트 오너로 입사했지만 대신 UX 라이터의 꿈은 어드민에서 마음껏(?) 펼치고 있다.
'검색어 입력', '제목 입력', '**배너 제목 입력', '배너 제목을 입력하세요' 등 여러 후보들을 써놓고 고민하다가 갑자기 슬랙 알림이 울렸다. 그리곤 갑자기 슬랙의 검색 placeholder가 눈에 띄었다.
첫 번째 슬랙 placeholder.통찰력 있는 독백 검색 (ㅠㅋㅋㅋ)
근데 원래 이거 아니었던 것 같은데? 하는 광기와 함께 새로고침하여 재 진입을 시도했다.
UX Writing 관점에서
1) 친절하게 도와주는 안내형: '함께 찾아봐요', '검색할 단어를 입력하세요. 나머지는 Slack이 해드릴게요.'
2) 무엇을 입력해야 하는지 명확하게 알려주는 정보 제시형: 파일, 정보, 수치, 통계, 데이터, 누락된 링크 등
3) 칭찬형: '검색어를 입력하세요. 잘하셨어요.', '답변을 찾아보세요. 기쁜 일이네요.'
4) 진행상황 표기형: '적절한 위치를 탐색 중입니다.', '이제 창이 열렸습니다.'
5) 고객 공감형: '분명히 여기 어디쯤인데...'
6) 자뻑(?)형: '스크롤하는 것보다 빠를 테니 검색하세요.', '무엇이든 검색하세요.'
등을 찾아볼 수 있었다. 약 20개의 placeholder가 랜덤 하게 노출되었는데, 다른 국가는 더 많을 것 같았다.
이번엔 혼자서 인풋창 테스트 시나리오를 짰다.
사실 업무용 툴이다 보니 가나다 123 abc ABC !@#$ 공백 등은 당연히 입력되었는데..
글자수가 길어지자 가로 스크롤바가 생기기 시작했다. 사실 평소에 이렇게까지 검색해본 적이 없다 보니 문득 궁금해져서 최대 글자수는 몇 자일지 엄청나게 입력해보기 시작했다. 그 결과...
최초 최다 입력 시도 시,
최초로 많이 검색했을 때 최초로 검색어 입력이 무시될 때까지 입력해 봤더니 대략적으로 위와 같은 수치가 나왔다.
여러 문자를 섞어 썼기 때문에 byte 기준이 달라 정확하진 않지만 꽤나 긴 분량이었다. 코드를 그대로 복붙 하는 경우를 대비해 검색창의 최대 입력 정책이 큰 것 같았다. 혹시 몰라서 최초가 아닌 두 번째 시도에도 동일한 정책인지 확인해 보았다.
두 번째 최다 입력 시도 시,
나의 한계..ㅎㅎ기존보다 더 많은 텍스트를 입력할 수 있었다. 사실 더 입력할 수 있었는데, 내 시간이 아까워 포기하였다.
사건의 전개
다시 본론으로 돌아와서, placeholder가 도대체 몇 개인지 궁금증을 해결하기 위해 슬랙에 이메일을 넣었다.
그리고 답장이 왔다.
나도 한글로 보낼걸;;
그다음 날, 실제로 슬랙의 한 직원 분께서 따로 메일이 왔다.
진행상황도 공유해주는 모습이 인상적이었다. 한편으로는 정말 알려줄까? 하는 마음도 들었다. 반대로 나도 이런 질문을 받게 되면 프로덕트 관리자로서 어디까지 알려줘야 할까 등의 고민도 해보았다.
사건의 결말
그다음 날, 또 한 통의 메일이 도착했다.
센스 있게 KFC의 비밀가루 사건과 비교하며 알려주지 않겠다는 답변을 담고 있었다. 그 이후 NPS에서 친절하고 빠른 응대를 칭찬하며 나의 궁금증은 마무리되었다. (옛날에 KFC 양념 가루들이 맛있어서 한동안 사람들이 레시피를 찾고 다녔음. 현재 약 11개로 추정되고 있음.)
에필로그.
사실 저 메일을 보낼 때는 눈치를 못 챘는데, 이 글을 쓰기 위해 다시 여러 번 테스트를 해 본 결과 어느 정도 공통된 규칙을 발견하였다. 쨌든 이번 사건(?)을 통해 배운 점이 두 가지가 있다.
1. 정책을 세울 때 고민이 되면, 반대로 내가 고객인 타사의 여러 제품을 직접 써보자.
: 단순해 보이는 인풋창도 SaaS 기업은 2000자가 넘는 byte를 커버하고 있다는 사실을 알게 될 것이다.
2. 내가 좋아하는 제품에 대해 궁금한 점이 있다면 직접 물어보거나 영어로 찾아보자.
: 작년에는 제품 기획/관리에 궁금한 점이 있다면 주로 카카오 브런치에 검색하거나 온라인 클래스 플랫폼에서 강의를 듣곤 했다. 올해는 현직장이 영어를 많이 쓰다 보니 자연스럽게 구글에 영어로 검색해 아티클을 찾아보고, 위와 같이 직접 본사에 메일을 보내 물어보기도 하였다. 영어로 검색하면 훨씬 더 많은 자료와 고민들이 나온다.
2023년에는
영어와 더 친해지는 스테이시가 되면 좋겠다.
길었던 호기심 탐구 끝.
