The Daily UX Writing Challenge

학창시절에 영문법은 확실히 제가 좋아하는 과목이 아니었습니다. 사실 나는 그것을 싫어했다. UX라는 바다에 깊숙이 들어가면서 아름다운 UI 화면을 디자인하는 것은 얕은 부분에 불과하다는 것을 깨달았습니다. 의미 있는 단어로 UI 화면을 보완할 수 있다는 것은 모든 개발 프로세스에서 매우 중요한 부분입니다. 학창시절 문법을 싫어하던 사람이 20대 중반에 돌아와서 물어뜯고..안아주기 위해 돌아왔다고 합시다. 잘못된 사본이 있는 웹 사이트와 앱 덕분에 UX 글쓰기는 결국 저에게 성장했습니다. https://dailyuxwriting.com은 UX 작성 여정을 시작하는 좋은 방법입니다. 이 일련의 UX 작성 프롬프트는 받은 편지함으로 직접 우편으로 15일 동안 퍼집니다. 완료하는 데 15일 이상이 걸렸습니다. 도전하는 동안 제 사고 과정을 엿볼 수 있습니다. 도전 01 — 항공편 취소 01일 사고 과정 여기에서 나는 마지막 다리 비행이 취소되는 것이 확실히 기분 좋은 느낌이 아니기 때문에 가능한 한 똑바로 하고 싶었습니다. 나는 무료 식사를 제공함으로써 손실을 보상하는 자유를 얻었지만, 나는 말장난을 하고 그들의 기분을 좋게 하기 위해 설탕을 입히고 싶지 않았습니다. 취소 사유와 항공편 번호에 대해 구체적으로 지적했습니다. 승객이 다음에 알고 싶어하는 매우 분명한 것은 상황을 어떻게 처리해야 하는가입니다. 따라서 팝업에 대한 CTA는 고객을 헬프라인으로 안내해야 했습니다. 예정된 항공편 목록을 표시하고 앱을 떠나지 않고 티켓을 양도할 수 있도록 하는 것은 고객 유지를 위한 항공사 POV에서 생각한 것입니다. 도전 02 — 스포츠 앱 광고 02일 사고 과정 이 프로모션의 주요 의도는 사용자의 관심을 끌고 앱을 다운로드하도록 하는 것입니다. 그래서 프로세스를 거꾸로 시작했고 CTA는 다운로드 링크여야 했습니다. 이제 그들이 다운로드하는 이유 — 글머리 기호는 글머리 기호를 관련 아이콘으로 교체한 것을 제외하고는 앞으로 나아갈 가장 좋은 방법이었습니다. 사용자의 주의 집중 시간이 매우 짧고 프로모션이 텍스트가 무거워지는 것을 원하지 않았습니다. 여기서 아이콘이 도움이 되었습니다. 사용자의 관심을 끌어야 했습니다. 일하는 부모의 페르소나는 바쁘다는 것이 당연했습니다. 그리고 제가 헤드라인에서 뻔한 질문을 했을 때, 긍정적인 대답은 그들의 눈을 굴리게 하고 앱의 장점을 읽게 할 수 있습니다. 그것으로 사이클을 완료합니다. 과제 03 — 이메일을 잊으셨나요? 03일 사고 과정 Forgot Email은 거의 모든 애플리케이션에 있는 매우 일반적인 흐름입니다. 이 작업은 두 부분으로 구성됩니다. 하나는 사용자에게 입력한 이메일 ID가 잘못되었음을 알리는 것입니다. 둘째, 그들에게 탈출구를 제공합니다. 사용자에게 잘못된 이메일 ID를 입력했다고 말하는 대신 앱이 책임을 지고 그러한 이메일 ID가 데이터베이스에 존재하지 않는다는 사실을 사용자에게 알리기를 원했습니다. 작업의 두 번째 부분에서 사용자는 계정이 없거나 잘못된 이메일 ID를 잊어버렸거나 입력했습니다. 이러한 각 시나리오에는 앱에 고유한 흐름이 있으며 흐름의 트리거 지점은 동일한 페이지에 있어야 합니다. 따라서 CTA와 보조 버튼입니다. 도전 04 — 구독 프로모션 04일 사고 과정 제 생각에는 이 작업은 신중하게 처리되어야 했습니다. 사용자인 이유는 식료품점에 있고 프로모션은 택배 구독에 관한 것입니다. 따라서 여기에서 문제는 상점에서 떠나라고 요구하는 것이 아니라 배달 서비스와 이용 가능한 제안을 알리는 것이었습니다. 광고 본문이나 헤드라인에 ' 배달할 때 매장에 왜 와? ' . 그것은 배달 서비스 제안을 광고하는 좋은 방법이지만 매장에 오는 사용자의 노력을 폄하하고 싶지 않았습니다. 이러한 인앱 광고 팝업에 대한 또 다른 성가신 점은 오른쪽 상단 모서리에 있는 나노 크기의 ' X ' 를 닫는 것입니다. 내 개인적인 경험을 염두에 두고 ' 나중에 알림' 옵션이 기본 버튼 옆에 배치되었습니다. 과제 05 — 앱 충돌 및 복구 05일 사고 과정 나는 이 챌린지를 위해 두 개의 사본을 생각해냈고 하나에 집중할 수 없었습니다. 위에서 두 가지를 모두 보여 드렸으며 그 이유는 다음과 같습니다. 저장된 파일의 버전이 있을 것이며 앱은 사용자를 마지막으로 저장된 버전으로만 되돌릴 수 있습니다. 또는 앱의 자동 저장 옵션이 매우 강력하여 사용자가 충돌 전에 중단한 위치에서 다시 시작할 수 있습니다. 두 접근 방식 모두 더 나은 사본보다는 기술에 더 기반을 두고 있습니다. 챌린지 06 — 로드 블록 06일 사고 과정 여기서 첫 번째 목표는 사용자의 관심을 최대한 빨리 얻는 것이었습니다. 빨간색. 영향을 미치기 위해 위험의 색을 눈에 띄게 사용해야 했습니다. 실제 위험 지역의 위치만 알고 있었기 때문에 비상 시 대체 경로를 제안하고 싶지 않았습니다. 챌린지 07 — 점수 업데이트 07일 사고 과정 여기 인도에서 크리켓은 종교이며 크리켓 선수를 숭배합니다. 내가 볼 수 없는 진행 중인 경기가 있다면, 나는 확실히 점수를 따라갈 것입니다. 푸시 알림은 의심할 여지 없이 사용자가 전화기를 잠금 해제하지 않고도 사용자의 관심을 끌 수 있는 가장 좋은 방법입니다. 그래서 여기 내 헤더가 점수여야 했습니다. 경기장에서는 스포츠 광신도가 관심을 가질만한 많은 일이 일어날 것입니다. 사용자가 처한 시나리오를 고려할 때 점수와 함께 최신 사건을 설명하는 한 줄의 라이너가 좋은 카피가 될 것입니다. 챌린지 08 — 콘서트 티켓 08일 사고 과정 제 생각에는 사용자가 티켓을 구매하도록 하는 가장 좋은 시간은 사용자가 앱에서 음악을 듣고 있을 때입니다. 그래서 그들의 플레이 시간 동안 배너는 내가 생각한 것입니다. 배너 콘텐츠에 등장하는 아티스트의 최근 콘서트 모습이 고퀄리티 이미지로 시선을 사로잡는다. 콘서트 시간과 장소 같은 정보를 더 추가했습니다. 공연이 무료인지 유료인지 확신이 서지 않아 구매라는 단어를 사용하지 않기로 했습니다 . 대신 Get Tickets를 사용했습니다 . 도전과제 09 — 신용카드 만료 09일 사고 과정 신용 카드 세부 정보는 일반적으로 구매의 마지막 단계에서 제공됩니다. 모든 전자 상거래 조직의 가장 큰 두려움은 사용자가 장바구니를 버리는 것입니다. 이 흐름에서 쉽게 벗어날 수 있는 방법을 제공하는 것이 이 과제의 핵심이었습니다. 카드의 기존 세부 정보를 업데이트하고, 새 카드를 추가하고, 사용자에게 다른 결제 모드를 시도하도록 요청하는 것이 제가 생각할 수 있는 가능한 방법이었습니다. 챌린지 10 — 추가 정보 10일차 사고 과정 아마도 자동차 웹사이트를 방문하는 모든 고객은 잠재 고객으로 간주됩니다. 이것이 이름이 필요한 이유에 대해 생각할 수 있는 유일한 이유입니다. 웹사이트는 전역 템플릿이므로 우편번호를 입력하면 위치별 정보가 표시될 수 있습니다. 실제로 어떤 사용자도 웹사이트를 먼저 살펴보지 않고는 미리 세부 정보를 기꺼이 공유하지 않을 것입니다. 그래서 (이번 챌린지에서) 회사의 진짜 동기를 모른 채 이렇게 민감한 정보를 요구한 것은 생각할 가치가 있는 일이었습니다. 한참을 고민한 끝에 정중하면서도 정확한 이유를 밝히지 않고 중간 입장을 취하기로 했다. Mandatory , Required, Necessary, Compulsory 와 같은 단어를 사용하지 않도록 했습니다 . 위에서 디자인한 팝업에서 취소 버튼이나 닫을 수 있는 십자 표시가 없음을 알 수 있습니다. 따라서 필드가 계속 진행되어야 함을 나타내는 막 다른 골목처럼 작동했습니다. 약간의 브랜드 표현을 추가하기 위해 버튼 텍스트를 대신 ' Vroom '으로 명명했습니다.진행 또는 다음 또는 제출 . 과제 11 — 메타 설명 11일차 사고 과정 메타 설명은 Google 검색을 수행할 때 URL 아래에 표시되는 텍스트입니다. 나도 이 도전에 직면하기 전까지는 이것에 대해 전혀 몰랐다. 여기서는 회사의 SEO 및 매출 전환(웹사이트에서 예상되는) 관점에서 생각해야 했습니다. 제 생각에는 검색 엔진의 결과에서 회사의 웹 사이트로 사용자를 이동시키는 한 번의 클릭이 가장 중요합니다. 메타 설명 제목의 한계를 고려하여 가장 중요한 서비스를 짜야 했고 이를 위해 사용자가 이 페이지를 훑어보는 동안 문장으로 갈 수 없었습니다. 메타 설명 자체는 160자로 제한되어 있습니다. 웹 사이트의 랜딩 페이지나 현재 제공되는 특별 서비스에서 보는 거의 모든 정보를 사용자가 얻을 수 있도록 했습니다. 내 의도는 그들이 더 많은 정보에 대한 질문 없이 링크를 클릭하고 렌즈를 예약하도록 하는 것이었습니다. 과제 12 - 오류 메시지 12일차 사고 과정 이 도전에 대해 읽었을 때 떠오른 이름은 X Æ A-12 — Elon Musk의 아들이었습니다. 나는 세상의 어떤 데이터베이스도 그러한 이름을 가지지 않을 것이며 모든 사기 탐지기가 그것이 가짜라고 생각할 것이라고 확신합니다. 이것은 이 과제에 대한 최상의 사용 사례 시나리오입니다. 저는 챌린지 03에서 언급한 원칙을 사용했습니다. 사용자에게 자신의 이름이 가짜라고 말하는 대신 비난을 받도록 합시다. 백엔드 데이터베이스에 등록되도록 이름을 추가하는 옵션을 제공했습니다. 그리고 여기서도 데이터베이스 나 백엔드와 같은 전문 용어를 사용하지 않았습니다. Google 또는 Facebook에서 로그인할 수 있는 옵션을 제공하는 것도 탈출구 중 하나였습니다. 과제 13 - 연료 딜레마 13일차 사고 과정 여기서 많은 도전이 저에게 말장난을 할 수 있는 선택권을 주지 않았습니다. 여기에서 나는 기회를 보았고 알림 자체에 경로 유지 또는 연료 공급 버튼과 함께 기발한 한 줄을 넣었습니다. 사용자의 주의를 끌기 위한 빨간색 알림 헤더 및 시각적 신호를 제공하는 아이콘 추가와 같은 표준 디자인 규칙이 처리되었습니다. 과제 14 — 일반 오류 템플릿 14일차 사고 과정 나는 이것이 무언가가 깨졌을 때 개발자들이 사용하고 싶어하는 일반적인 템플릿이 될 것이라고 믿습니다. 세부 사항에 들어가지 않고 사용자에게 문제가 있음을 알립니다. 그들이 앱에 머물도록 하는 것이 또 하나의 작업이었습니다. 새로 고침 버튼을 배치하는 것이 제가 생각할 수 있는 해결책이었습니다. 어떤 것이 작동하지 않으면 사람들은 보통 전원을 껐다가 다시 켭니다. 웹사이트에 있을 때 풀다운하고 새로고침합니다. 휴식이 빠른 수정인 경우 여기에서 동일한 작업을 수행하고 앱에 유지하기를 원했습니다. 챌린지 15 — 온보딩 경험 15일차 사고 과정 앱 이름으로 시작하여 Bill과 List라는 두 단어를 결합했습니다. 정시에 자동으로 지불할 청구서 목록을 보관하는 입니다. 스플래시 화면의 경우 — 앱의 정체성과 브랜드를 표현하기 위해 미묘한 캡션이 필요했습니다. 그 기능은 사람의 개입 없이 정시에 청구서를 지불하는 것이기 때문에 귀하의 청구 파트너가 저에게 딱 맞는 것 같았습니다. 세컨드 스크린에서는 삽화에 적절한 단어를 붙여야 했습니다. 그림이 추적할 청구서 목록을 묘사한 경우 단어는 그것으로 수행할 작업을 설명해야 했습니다. 아래로 스크롤하면서 앱과 프로필을 설정하는 것이 얼마나 쉬운지 나타내려고 계획했습니다. 숫자를 강조하면서 사용자에게 3단계 프로세스임을 알리고 있었습니다. 링크/체인/시퀀스와 같은 시각적 신호가 도움이 되었습니다. 시작하는 버튼은 온보딩 화면의 끝이었습니다. 사용자는 온보딩 화면을 건너뛸 수 있는 기능이 있어야 하며 이 기능도 포함되었습니다.