토스 UX Writing - 가이드라인>시스템

가이드라인을 시스템으로 만드는 법

토스의 UX Writing 시스템이 만들어지는 과정에 대한 이야기

1~2분이면 읽어지는 글을 적어내기까지 얼마나 많은 설득과 논의들이 오고 갔을지

어렴풋하게 짐작하면서도 짐작이 잘 되지 않는듯하다.

(원문 링크 : https://toss.tech/article/introducing-toss-error-message-system)

↓아래는 아티클을 보면서 들었던 내 생각들 정리

무작정 모든 제품에 있는 에러메시지를 워싱하고 팀원들에게 설득하기까지 얼마나 많은 과정이 있었을까 싶다. 지나고 나서 뒤돌아보면 문제>해결의 과정만 보이기 때문에 간단해 보이지만 앞이 보이지 않는 상황에서 문제를 명확하게 짚어내고 해결해 나가는 과정은 참 쉽지 않았을 것 같다.

1. 에러메시지 문구를 설계하는데 있어서 단지 '해요체 vs 합쇼체'의 변화만으로 사용자가 느끼는 불편함이 사라지는 것이 아니라 사용자에게 오류의 원인을 상세하게 설명해주지 못했기 때문이라는 부분을 명확히 짚어낸 점

2. 해요체와 합쇼체가 같이 쓰이게 되었을 때 토스 앱에서의 일관성을 헤치는 요인이 될 것이라는 점

이 두 가지를 가지고 해요체를 고수하면서도 사용자에게 적합한 부가 설명을 덧붙여서 에러 메시지 UX Writing을 개선해나간다는 방향을 잡았다는 점에 작은 감탄을 하고 간다.

UX나 UI와 관련된 작은 프로젝트만 진행해봐도 작은 의사결정들이 모여 어느순간 출발 지점과는 아주 동떨어진 어딘가로 가게되곤 한다. 그래서 문제점과 해결방향을 정확하게 짚고 해결을 위한 실마리를 찾아가는 의사결정 과정의 일부를 보면서 문제 정의와 해결 방법에 대한 힌트를 얻는다.

또, 비슷한 상황을 카테고리화하고 각각의 상황에 맞는 문구를 템플릿으로 만들고 원칙을 세웠다는 점이 고무적이다. 모든 상황을 세분화해서 템플릿을 만들고, 이것을 라이브러리화 해서 에러메시지를 주로 입력하는 개발자와 디자이너가 반복적으로 커뮤니케이션하는 비용와 시간을 줄였다.

제품에 일관성을 부여하기도 했고! 김자유님이 디자이너 > UX Writer가 되어서 그런지 컴포넌트화하고 라이브러리화해서 필요할 때마다 꺼내서 조금씩 고쳐쓴다는 개념을 Writing에도 잘 적용시킨듯하다!

무엇보다도 UX Writer는 혼자 잘 쓰는 것이 아니라 함께 잘 쓰는 것이 중요하다는 점을 아티클의 말미에 한 꼭지로 넣어둔 점이 인상적이었다.