본 글은 Goodpatch blog에서 보고 필자가 번역하였습니다.
원문은 Goodpatch의 iOS Developer ‘usagimaru’ 님이 작성했습니다.
다이얼로그(Dialog)란
다이얼로그란, 유저와 문장으로 대화하는 유저 인터페이스 요소입니다. 그중에서도 알럿(Alert)은 에러 메세지나 경고를 유저에게 알리고, 알림을 통해 이어지는 행동 (동의/거부 등)을 묻기 위해 사용합니다. 유저는 자신이 하고 있던 작업을 다른 이에게 빼앗겨버리고 싶지 않기 때문에, 알럿을 많이 사용함에서는 충분히 조심해야 할 필요가 있습니다.
“취소”의 [OK]와 “취소”의 [취소]
먼저 이미지를 봐주시기 바랍니다.
이 알럿은 설명문(title)에서 작업중단의 시비(是非)를 유저에게 묻고난 뒤, [취소]와 [OK] 두 선택지를 액션으로써 나타내고 있는 알럿의예 입니다. 이것을 보고 무언가 위화감을 느끼는지요?
이 문맥은 [편집내용 취소]를 실행해도 되느냐를 유저에게 확인하고 있습니다. 취소에 동의하고 싶은 많은 유저들은 직감적으로 같은 표기의 [취소]를 선택하고 싶을 것입니다. 하지만 그렇게 되면 편집 취소는 실행되지 않습니다.
이 취소 버튼이 의미하고 있는 것은, [편집내용 취소]를 [취소]인 거죠. 즉, 유저가 원하는 대로 편집내용을 파기하기 위해서는 반대쪽의 [OK]버튼을 선택해야만 합니다. 이처럼 “취소”의 [취소]는 이중부정으로 의미가 복잡해지므로 피해야 합니다.
여기서 “취소”의 [취소]로 되지 않게 하기 위해 다음과 같은 버튼 이름을 변경해 보았습니다.
이걸로 망설임은 좀 나아지셨나요…?
저는 변경된 표기에도 잘못이 있다고 판단합니다. [네], [아니요] 는 결과를 예상하기 어려운 표현이므로, 다이얼로그 액션 버튼에 사용하는 건 적절치 않습니다.
또한, 몇몇 알럿의 잘못을 짚어보고자 합니다. “이걸로는 설명이 되지 않아!” 라며 주변의 불만에 답하는 형식으로, 다음과 같은 설명문을 확장해 보았습니다.
네. 아니, 아니요?
이 알럿의 경우 최종적으로 “저장을 권합니다”라고 묻고 있으므로, 그렇게 하고 싶은 유저는 분명 직감적으로 [네]를 선택할 것입니다. 그러나 [네]를 선택하게 되면 본래의 질문인 [편집내용 취소] 가 실행되어버리기 때문에, 이걸로는 편집내용의 저장은커녕, 반대로 파기되어버리고 맙니다. 이것은 유저에게 최악의 전개입니다.
짧고 논리적인 동시에 적절한 문구를 디자인하기
위의 알럿의 예는 문구가 부적절한 데에서 유래한 문구 버그 입니다. UI 디자인 프로세스에서 문구디자인은 비교적 간과되어버리는 경향이 있습니다만, 몇 가지 점에 주의한다면 문구 버그는 막을 수 있습니다.
다시 처음의 알럿을 보겠습니다.
이 알럿은 처음부터 설명문이 적절하지 않습니다. 그리고 선택지 버튼 이름도 잘못되어 있습니다.
먼저, 설명문 중에 [취소]라는 단어가 버젓이 사용되고 있는 것이 부적절합니다. 취소는 부정적 버튼에 잘 쓰이는 단어이므로, 이것과 혼동하기 쉬운 질문은 피하도록 해주세요.
취소의 의미를 혼동하는 좋은 예로 쇼핑 앱에서의 주문취소처리 중에, “주문을 취소하시겠습니까?”라는 알럿입니다. 여기서 말하는 [취소]는 물음의 부정이 아닌, [주문취소]가 됩니다. 만약 의미를 혼동한다면 이것을 일부러 가로로 쓸 필요가 없고, 바로 [주문취소]라고 표기하면 좋습니다. [취소]는 GUI의 예약어와 같은 것이기 때문에, 취소 버튼 이외에 [취소]라는 단어를 사용하는 것은 피하는 것이 좋겠지요.
다음으로, 버튼 이름은 설명문에 대응하는 동사여야 합니다. 위의 예시에서의 [예], [아니요]는 동사가 아니므로 유저는 그 액션 후의 결과를 예상하기 어렵습니다. [예], [아니요]로 그 의미를 이해하는데 동사 표기보다 시간이 더 걸리게 됩니다.
이렇듯, 비논리적인 문구를 버튼 이름으로 채택하는 것은 적절하지 않습니다. 또한, 위에서 서술한 바와 같이 부정적 액션의 명칭은 가능한 한 [취소]라고 통일합시다. 이 [취소]라는 단어는 플랫폼(iOS, macOS 등)에서 통일된 부정표현입니다.
동의 버튼은 문맥으로서의 [OK]가 위화감이 없다면 사용 가능, 좀 더 구체적으로 표기할 필요가 있는 경우에는 [설명문이 묻고 있는 내용을 나타낸 동사]를 그대로 버튼 이름으로 사용합시다.
이번 알럿 예시는 “파기하시겠습니까?”라는 설명문이므로, 동의 버튼 이름은 [파기]로 됩니다.
어떻나요? 처음 알럿에 비하면 꽤 이해하기 쉬워졌습니다만, 아직도 개선의 여지가 있어 보입니다.
“~하다" 표현을 가급적 피하고, 간결하게 표기하자
버튼 문구 디자인에서 주의할 점은, “~하다”라는 표현을 가급적 피하는 것입니다. [취소하기], [파기하기], [삭제하기], [선택하기], [다운로드하기]……이들은 모두 [하다]가 쓸데없이 장황하다는 느낌을 받게 합니다. 문맥 나름이라 생각합니다만, 대개 “~하다” 형태가 아니어도 의미는 통하므로 짧게 표기합시다.
한편, 앱 디자인 언어에 따르면 “~하다” 표기 등이 바람직한 경우도 있습니다. 예를 들어, [계속]보다 [계속하기]의 경우가 더 부드러운 느낌을 주고, 실제로 더 많이 사용됨을 볼 수 있습니다.
설명문에서 존대어 등의 번거로운 표현은 많이 사용하지 않는 것이 바람직합니다. 위에 예시에서 “~하시겠습니까?”라는 물음이었습니다만, 이 문맥을 해독하면, 편집 내용을 파기하는 것을 결정하는 건 유저이므로 주어는 유저가 될 수 있습니다. 그러므로 이 설명문은 “~하겠습니까?”라고 단축할 수 있습니다.
유저는 문장을 읽고 싶은 것이 아니라 자신이 원하는 콘텐츠에 액세스 하고 싶을 뿐입니다. 번거로운 표현은 유저를 콘텐츠로부터 멀어지게 합니다.
파괴(破壞)적 액션을 고려하자
설명문에는 동의 액션과 같은 언어표현 [파기]라는 단어를 담은 것으로 고쳐 씁니다. 여기에서 동의 액션, [파기]는 동시에 파괴적 액션이므로, Destructive 스타일(빨간 글씨)로 합니다.
그러면 이렇게 됩니다.
[파기]는 파괴적이지만, 동시에 이 문맥에서는 동의 의미가 있으므로, HIG에 따라 오른쪽에 배치합니다. 파기의 부정인 [취소]는 왼쪽에 배치합니다.
뭐, 괜찮게 된 것 같습니다만, 실은 큰 잘못이 있습니다.
액션 시트(Action sheet)의 역할
알럿은 이걸로 완벽하게 보일 수 있습니다만, 사실 알럿이라고 하는 것 자체에 처음부터 문제가 있었습니다. 알럿은 유저가 의도치 않게 발생한 이벤트(에러 등)에 대해 어떻게 처리할 것인가, 유저의 판단을 받들기 위해 이용하는 모달 뷰(Modal view)의 일종입니다. 그것에 입각하면, 이번 [편집내용 파기]라 하는 문맥에는 맞지 않습니다. 이 알럿은 유저가 능동적으로 닫는 버튼 등을 눌렀을 때 나타나는 확인 알럿이므로, “유저가 의도치 않게 발생한 이벤트”라고는 말할 수 없습니다.
자 이제 액션 시트의 차례입니다. 액션 시트는 유저에게 두 가지 이상의 액션을 제시하여 유저의 판단을 받아들일 수 있습니다. 이번처럼 유저 액션에 연동한 콘텐츠 파기를 묻는 장면에서는 최적이라 할 수 있습니다. 또한, 알럿이 가능하다 생각되는 장면이 있다 하더라도 선택지가 많은 경우에는 액션 시트의 이용을 검토 바랍니다.
액션 시트는 반드시 취소에 해당하는 버튼을 하나 가지고 있어야 하며, 선택지에 취소를 포함한 두 선택지 이상이 보입니다. 유저는 언제든지 액션실행을 중단할 권리가 있습니다.
꽤 괜찮게 된 것 같네요.
액션 시트의 버튼 배치를 생각하자
위에서 완성한 액션 시트. 거기에 저장할 것인가, 아닌가를 동시에 묻는 것도 좋을 것 같습니다. 그것을 위한 버튼을 하나 더 추가해 볼까 합니다만, 다음과 같이 두 가지 패턴으로 생각할 수 있을 것 같습니다.
[파기]를 위에 배치하는 것이 좋을까, 그 반대일까. 참고로 Apple Mail, Twitter, Facebook에서의 사례를 비교해 보면 이렇게 됩니다.
Apple Mail과 Twitter에서는, 파괴적 액션인 파기 버튼이 취소 버튼과 가장 먼 위치에 배치되어있는걸 알 수 있습니다. (이것은 동시에 손가락과도 가장 멀리 떨어진 위치라고 볼 수 있죠). 한편, Facebook에서는 저장과 삭제의 위치가 역전되어 있습니다. 게다가 취소(Cancel)가 아닌 [Go Back]이라고 되어 있는 부분이 크게 다릅니다.
Facebook의 이 의도는 잘 모르겠지만, 일방적인 삭제와 저장을 나란히 배열한 액션 시트는 Apple의 방식을 따르는 것이 올바르겠지요. 취소 버튼도 [Go Back]이라는 독자표현이 아닌 여기는 바로 [취소]라고 하는 것이 안전하다고 생각합니다. 저는 Facebook의 액션 시트를 봤을 때, 엄청난 위화감을 느껴 잠시 생각에 잠겼습니다. 그 위화감의 정체는 Mail이나 Twitter와 같이 표준적 배치가 아닌 다른 배치에서 왔고, 특히 삭제라는 위험한 작업을 수반하는 과정에서는 신중해질 수밖에 없었습니다.
위의 내용을 바탕으로, 이번 액션 시트의 디자인은 [A]가 정답입니다. 앱 디자인 언어를 정의해서 독자성을 연출하는 것도 중요하지만, 일단은 플랫폼 디자인 언어에 따르는 것이 더욱 중요하겠지요.
선택지가 없는 알럿 버튼의 문구를 생각하자
알럿은 때때로 정보전달의 역할만으로 머무르는 경우가 있습니다. 신기능 정보 같은 알림을 표시할 때 액션 버튼 하나로 알럿이 사용되는 일이 있습니다. 그때, 액션 버튼의 문구는 어떻게 하나 생각할 여지가 있을 것입니다. [OK] 버튼으로 두는 게 일반적이지만, 문맥에 따라 다른 문구도 검토할 수 있습니다.
하나의 액션 버튼인 경우는 디폴트 스타일(Bold)이 좋다고 생각됩니다.
알럿 자체에 대한 액션을 피하자
알럿에서 나가는 의미로 액션 버튼을 [닫기] 혹은, [돌아가기]로 하는 것은 피하는 게 좋겠지요.
[닫기], [돌아가기]의 문맥을 생각했을 때, 이들의 목적어는 [알럿] 자체를 말합니다. 문장으로 고치면 [알럿을 닫기], [알럿을 닫고, 알럿을 표시하기 이전의 상태로 돌아가기]라는 의미가 됩니다만, 알럿을 닫는다는 것은 너무나 당연한 일이고, 일부러 [알럿을 닫기]라는 선택지를 유저에게 보여서 그것을 누르게 할 필요는 없습니다. 동의도, 부정도 어떤 선택이든 액션 버튼을 누르면 알럿은 절대적으로 닫치기 때문에, 버튼을 선택한 결과가 어떻게 되는지를 설명할 수 있는 단어가 바람직합니다.
만약 액션 버튼 이름에 [닫기], [돌아가기]라는 문구를 사용하고 싶을 땐, 꾹 참고 [OK]를 채택하기를 바랍니다. 대부분의 경우 [OK]로 문제없이 성립됩니다.
알럿을 많이 사용하지 않기
다이얼로그는 유저의 작업이나 의식에 강제로 개입하는 모드입니다. 유저의 자유를 지키기 위해서도 시스템에서 발생하는 알럿은 가급적 사용하지 않는 것이 바람직하겠지요. 예를 들어 알림 명목으로 알럿을 사용하거나, 단지 액션의 결과로 피드백할 경우, 알럿을 안이하게 사용하는 것은 피합시다.
마치며
앱에 다이얼로그를 넣을 때는 다음 사항에 주의하여 디자인합시다.
간결하고 알기 쉬우며, 일관된 문구 표현을 의식하기
“취소”의 [취소]에 대표되는 이중 부정 표현을 피하도록 합시다. 앱 또는 플랫폼에서 사용되는 표현을 존중하고, 표기가 흔들리지 않도록 주의합시다. [취소]는 물음의 부정 액션으로 시스템에서 넓게 사용되는 예약어와 같은 것입니다. [취소]를 이 이상의 용도로 사용하지 않도록 합시다.
액션 버튼 이름은 결과가 예측될 수 있도록 동사로 표기합시다. “~하기”를 어미로 붙일 필요는 없습니다. 많은 경우가 이에 해당합니다.
타이틀을 보충할 문장을 기재할 경우, 타이틀 레이블이 아닌 메시지 레이블(Description)에 추가기재 합시다.
플랫폼 룰에 따르기
iOS 혹은 macOS에서는 “동의 액션은 오른쪽에, 부정 액션은 왼쪽에 배치한다.” 라고 정의되어 있으므로, 정보의 배치 룰을 의식하도록 합시다. Windows OS나 오래된 Android OS에서는 룰이 반대로 되어 있으므로 주의해 주세요.
또한 iOS에서는, “파괴적 액션 버튼에는 Destructive Style(빨간 글씨)를 사용하기"라는 룰이 있습니다. 삭제를 하는 액션 버튼이 나타나면 Destructive Style을 검토 바랍니다.
유저가 능동적으로 행동하는 장면에는, 알럿이 아닌 액션 시트를 사용하도록 합시다.
macOS에서는, 주요 버튼은 return키, 취소 버튼은 esc키도 사용 가능함을 추천되고 있습니다.
주역은 유저와 콘텐츠
다이얼로그뿐만 아니라, 유저 인터페이스는 주역이 아닙니다. 유저와 콘텐츠를 이어주는 중개역으로써, 그들을 방해하지 않고 투명하게 작동하는 것을 목표로 합시다. [알럿 닫기]가 아닌, 유저가 행동하는 김에 알럿도 소멸하는 동작이 정답입니다. 알럿을 닫는 행위를 일부러 유저에게 의식하게 하지 않도록 주의합시다.
알럿을 많이 사용하지 않기
뭐든 알럿으로 하는 것은 피합시다. 서비스 알림, 즐겨찾기 등록 성공 취지의 통지, 신기능 소개 등, 유저의 핵심 경험을 생각했을 때 정말로 그것들이 필요한 것인가 잘 검토해 주세요.
시스템 장애나, 통신 에러 등, 예기치 못한 치명적인 장면에서 알럿을 사용하기를 권합니다.
