디자인
Gallery
Search
UX writing 매거진 (by 브런치 작가 Joo Jun님)
UX Writing
사실 한국어 UX writing의 역사는 짧지 않습니다. 적어도 13년 전부터 초창기 네이버의 훌륭한 테크니컬 라이터 분들이 네이버의 스타일을 정리하셨고, 삼성과 LG휴대폰의 UX 조직에 규모 있는 UX writing팀이 있어 왔습니다.
UX writer, Contents designer들의 고요한 성정 때문인지 몰라도 UX, UI, CX에 대한 글에 비해 한국어 UX writing에 대한 글이나 책도 많지 않았습니다. 책 역시 참고할만한 것이 무척 적은 상황인데,
『웹 기획자가 알아야할 서비스 글쓰기의 모든 것』 (2016)
외에는 한국어 UX writing에 대한 레퍼런스가 될만한 책은 사실 없었어요.
Facebook, Instagram, Google 같은 글로벌 서비스를 매일 쓰지만 묘하게 그들의 텍스트가 우리의 언어 감각과는 안 맞는 것 같은 불편한 느낌, 느끼신 적 있나요? 또한 해외 사례를 한국에 도입하려해도 언어 특성상 어려운 지점이 분명 있습니다.
이런 한국어 UX writing 상황에 대해 하고 싶은 말, 나누고 싶은 경험들을 일단 글로 써서 지식을 나누며, 나름의 의견을 내고자 이 시리즈를 작성합니다.
매거진의 목차는 대략 이렇습니다.
일단 UX writing의 주요 원칙에 대해서 살펴보고, UI 텍스트와 각 컴포넌트별 레이블 작성법에 대해서도 간단히 이야기합니다. 실무에서 designer와 writer가 뭘로 투닥투닥하는지, 어떤 이슈가 우리들을 힘들게 하는지도 알아봅시다.
우리에겐 한국어 writing 사례가 필요하므로 마지막에는 제가 이용하고 있는 서비스들의 UI 텍스트들도 중간중간 분석하는 가벼운 챕터도 준비하고 있습니다.
-----------------------
매거진 본문 중 특히 흥미로운 글을 B2B 디자이너 커뮤니티에 소개합니다.
UI 텍스트 쓸 때 종종 등장하는 '-하기' 어미에 대해 어떻게 생각하시나요? 글쓴이는 먼저 '-하기'를 자제하자는 요지의 글을 올렸었는데, 일부 특정한 환경에서는 필요에 따라 '-하기'를 써도 좋겠다는 후속 글을 올렸습니다.
잘 정리된 글이지만 작성자 개인의 의견이므로, 이 글을 읽으시는 분들께서 여러 의견을 표출한다면 한국어 UX writing 발전에 도움이 되지 않을까 싶습니다.
'-하기'를 그만하기
https://brunch.co.kr/@joojun/101
'-하기'형, 버튼이 왜 이래 (서비스의 욕망이 살그머니 드러나는 지점)
https://brunch.co.kr/@joojun/113
[통합 요약]
- 서술형 명사 2음절만으로도 충분한데도 '-하기'를 붙여서 억지로 명사를 만들어 쓸 필요가 없다. '-하기'를 반복해서 쓰면 텍스트 간결성, 가독성, 의미변별성이 모두 나빠진다.
- 4음절 선호는 그저 익숙함 때문이다. 긴 버튼에서의 양쪽 여백이 신경쓰인다면 톤 앤 보이스를 살려서 문장형 버튼을 적용하는게 차라리 낫다.
- 필요한 순간, 쓰고 싶은 순간에는 '-하기'를 써라. 다만 모든 버튼을 '-하기', '-기'로 끝내려 하지는 말자.
- '-하기'는 '-음'이나 서술형 명사보다 사용자 스스로가 해당 액션을 다짐하는 듯한 인상을 주기 때문에 앱 제작자는 CTA에 적용하고 싶어지는 느낌이 들 수도 있다.
- 마켓컬리 앱은 1) 컨트롤러로써 동작하는 기능적인 버튼에서는 명사 형태로 쓰고, 2) 사용자의 액션을 강력하게 끌어와야 하는 버튼에 '-하기'를 쓴다.
- '-하기'는 워낙 은근한 장치이기 때문에 사용자의 선택에 결정적인 영향을 미치는 일은 없다고 본다.
- 다만 가능하면 구매, 구독, 결제와 같이 서비스 입장에서 중요한 버튼에만 드물게 '-하기'를 붙이면 좋겠다.
🐌
달팽이
UX 디자인 검수란?
UX
가이드
문서 작성법
UX 디자이너들은 사용자에게 긍정적인 경험을 주기 위해 다양한 부서와 이해관계자들과 협업하며 자신의 디자인과 비지니스 전략이 일치하는지 확인합니다. 협업은 좋은 디자인으로 이어질 수 있지만 디자인의 일관성 문제, 접근성의 격차 등의 어려움을 겪을 수 있습니다. 이런 이유로 정기적인 디자인 검수를 계획하여 제거해야할 차이들을 찾고 측정하고 해결하는 것이 중요합니다.
디자인 검수란?
- 디자인 검수란 품질 보증 (Quality Assurance, 많이들 알고 있는 'QA')을 의미함. UX 관점에서 프로덕트가 접근성, UI 컴포넌트의 일관성 및 디자인 통합 요구사항을 충족하는지 평가함. 이 과정을 통해 디자이너들은 이전에 발견하지 못했던 이슈나 다음 디자인 스프린트에서 해결되어야할 이슈를 찾을 수 있다.
디자인 검수 과정에서 발견되는 흔한 이슈들
- 스크린 리더 사용자에게 필요한 이미지 대체 텍스트 누락
- 일관성 없는 폰트 타입 및 사이즈 사용
- 네비게이션 링크 누락
- 업데이트가 안된 구 콘텐츠
- 적절하지 않은 컴포넌트 사용 패턴
- 접근성 요건을 충족하지 않는 브랜드 컬러와 동떨어진 컬러 사용
- 레이아웃의 기준이 없어 컴포넌트 배치가 어수선하고 삐딱함
디자인 검수는 언제 해야 할까?
- 최대한 자주, 정기적으로 할 것.
- 디자인 검수를 미루면 미룰수록 이슈가 문제를 만들 가능성이 높아져 디자인 과정에서 해결하기 어려워짐.
웹사이트 디자인 검수 시 사용되는 방법들
10가지 사용성 휴리스틱
1) 시스템의 가시성
2) 현실세계와 부합 하도록 설계
3) 사용자에게 적절한 통제권을 부여
4) 일관성과 표준성 높이기
5) 사용자 실수 방지
6) 적은 인지적 노력
7) 유연하고 효과적인 사용성
8) 심미적이고 미니멀한 디자인
9) 사용자 스스로 오류를 인지하고 벗어날 수 있도록 설계
10) 충분한 도움말 제공
(
각 항목에 대한 더 자세한 내용 아래 아티클들 참고해보시면 좋아요.
- 닐슨&노먼 그룹 아티클 참고: http://abit.ly/0v8cec
- 국문은 이 브런치 추천 드립니다: https://brunch.co.kr/@hyoi0303/53 )
접근성 가이드라인
- 모든 사람들이 디자인을 사용할 수 있도록 설계되는 건 중요하다.
- 회사 내부에 접근성 지침이 없다면 'W3C 접근성 표준'을 참고 하는 것도 방법이다. (https://abit.ly/4njwod)
프로토 타이핑 도구를 활용해 UI 컴포넌트의 연속성과 일관성 유지하기
- 프로토타이핑 도구를 활용한 사용성 테스트를 통해 UI 구성 요소 패턴을 테스트 하기
스타일 가이드 라인 준수
- 프로덕트의 look&feel 과 Tone&Manner 에 대한 지침을 제공하는 문서를 잘 지키면 일관된 사용자 경험을 제공할 수 있다.
UX 검수 템플릿
- UX 검수 템플릿을 구축하여 팀에게 인사이트를 제공하는 것이 중요하다. 아래 항목들을 스프레드 시트의 열 제목 사용해서 각 문제들을 평가해보기.
1) 문제 설명: 무엇이 문제인지
2) 문제 위치: 문제가 어디서 발생하는지
3) 사용성 휴리스틱: 어떤 휴리스틱 요건이 충족되지 않는지?
4) 접근성: 접근성 문제인가? 예/아니오
5) 사용자에게 미치는 영향도: 얼마나 심각한 영향인지? 높음/중간/낮음
6) 디자인 수정 규모: 수정하는데 노력은 얼마나 드는지? 높음/중간/낮음
7) 개발 규모: 디자인 수정을 위해 개발 리소스는 얼마나 드는지? 높음/중간/낮음
8) 우선 순위: 위의 항목들 결과를 토대로 전체 우선 순위 설정하기
UX 검수로 얻는 인사이트
- UX 검수에서 가장 가치 있는 부분은 팀에서 다양한 관점으로 논의하고 합의한 UX 평가 기준으로 프로덕트을 평가 할 때 이루어 진다. 문제에 대한 계획을 좀 더 수월하게 할 수 있다.
🥁
김예진
Load more
그로스 전략
Gallery
Search
Load more
프로덕트 & 데이터 분석
Gallery
Search
🧐 문의 채널을 설계하는 방법
문서 작성법
경험 공유
프로덕트 전략
🌙
황새나래
경쟁사 UX 분석하기: 단계별 가이드
프로덕트 분석
UX
리서치
🥁
김예진
B2B 프로덕트의 UX 측정하기
UX
지표
🐼
정하영
'가치' 프레임워크
프레임워크
마인드셋
프로덕트 전략
프로덕트 분석
PM/PO
스타트업
🐼
정하영
Load more
워크 프로세스
Gallery
Search
Load more
성장의 피땀눈물
Gallery
Search
PM을 위한 API 해설
마인드셋
직무 분석
커뮤니케이션
PM과 소프트웨어 엔지니어가 레스토랑에 들어갑니다.엔지니어는 PM에게 API가 무엇이며 어떻게 작동하는지 레스토랑 일에 비유하면서 설명하기 시작합니다.
인증 (Authentication)
엔지니어: 회원 전용인 멋진 레스토랑에 간다고 상상해 보세요. 클럽 회원 자격이 있어야 레스토랑에서 식사를 할 수 있습니다.
PM: API에서 이것이 의미하는 바는 무엇인가요?
엔지니어: 레스토랑에 입장하려면 요트 클럽 레스토랑에 입장할 수 있는 신분증과 유효한 멤버십 카드가 필요합니다. 기술 용어로 API 사용 인증을 받으려면 ‘API 키 또는 토큰’ 이 필요합니다.
엔드포인트/목적지(Endpoint)
PM: 식당으로 가는 주소와 길을 알려주시겠습니까?
엔지니어: 주소는 '엔드포인트(http://xxx.com)'라고 부릅니다!
메소드, 요청과 응답 (Method, Request and Response)
PM: 이제 레스토랑에 도착했으니 음식을 주문하죠!
엔지니어: 여기 있습니다,
Method = Get
GET method 는 지정된 리소스의 서버에서 데이터를 검색하는 데 사용됩니다. (‘Method’ 는 API에 수행하도록 요청하는 '동사' 또는 '동작'일 뿐입니다.) 이 시나리오에서는 웨이터에게 레스토랑에서 제공되는 메뉴를 요청했습니다.
Request: 레스토랑에서 제공되는 항목 목록을 보도록 요청했습니다.
Response: 응답의 결과는 레스토랑에서 제공되는 항목 목록을 보여주는 메뉴를 얻는 것입니다.
Method = Post
상상의 요트 클럽 레스토랑에서는 원하는 음식을 찾지 못해 레스토랑의 주방장에게 전화를 걸어 맞춤형 “비건 버거” 새로운 요리를 요청합니다. 그리고 요리사는 이 새로운 항목을 메뉴에 추가하기로 결정했습니다!
이 시나리오에서 메뉴에 새 항목을 넣는 행위를 'Post‘ 라고 합니다.
Request: 셰프가 새로운 “비건 버거” 메뉴를 추가합니다. 요청에는 메뉴에 게시할 설명 및 가격과 함께 항목 이름이 포함되어야 합니다.
Response: 이 결과 '설명' 및 '가격'과 함께 “비건 버거”가 게시되고 메뉴에 표시됩니다.
Method = Put
“비건 버거”는 레스토랑에서 큰 인기를 얻었지만 터무니없는 가격에 요리사는 가격을 몇 달러 인하하기로 결정합니다.
이 시나리오에서 메뉴의 기존 항목을 업데이트하는 작업을 'Put'이라고 합니다.
Request: 셰프가 “비건 버거” 항목의 새 가격을 입력합니다. 요청 페이로드에는 업데이트 중인 항목의 참조 및 값과 함께 업데이트가 필요한 매개변수가 포함되어야 합니다.
Response: 이 결과 메뉴에서 “비건 버거”가격이 업데이트됩니다.
Method = Delete
“비건 버거”에 대한 수요가 급증하자 요리사는 메뉴에서 인기없는 다른 메뉴를 제거하기로 결정합니다.
아이템을 제거하는 행위를. API 용어로 ’Delete’ 라고 합니다.
Request: 셰프가 메뉴에서 '캐비아'를 제거해 달라고 요청할 것입니다. 요청 페이로드에는 메뉴에서 제거할 다른 세부 정보 중에서 항목 이름이 포함되어야 합니다.
Response: 이 결과 메뉴에서 '캐비아'가 더 이상 표시되지 않습니다.
상태 코드와 오류 메세지 (API Status Codes and Error Messages)
PM: 와우! API가 원하는 모든 작업을 수행한다는 사실이 마음에 드는군요.
엔지니어: API가 항상 잘 작동하는 것은 아닙니다. 종종 오류도 발생합니다. 아래 '응답 코드'를 통해 API의 동작 상태를 확인할 수 있습니다.
2xx : 요청이 성공했음을 의미합니다.
3xx : 운전을 해서 상상의 요트 클럽 레스토랑으로 가서 새 주소로 이사했다는 안내판과 호텔 직원이 새 위치 방향을 알려주는 안내판을 찾았다고 상상해 보세요. API 용어로 요청이 다른 URL로 리디렉션됨을 의미합니다.
4xx: 레스토랑으로 차를 몰고 가 '캐비아'를 주문했는데 더 이상 레스토랑에서 제공되지 않는다는 사실을 알게 되었습니다! 이는 클라이언트 오류(승인되지 않음, 금지됨, 페이지를 찾을 수 없음)와 동일합니다.
5xx: 이 경우에는 레스토랑의 문제입니다! 비건 버거를 주문했지만 대기열이 길고 항목을 만드는 데 시간이 오래 걸렸습니다. API 용어로 그것은 서비스를 사용할 수 없거나 게이트웨이 시간 초과를 의미합니다.
Load more