OK-Cancel or Cancel-OK ?
확인 버튼과 취소 버튼의 위치는 어떻게 설정할까?
최근 프로젝트 진행 중 Mac/ Windows 두 가지 OS용 어플리케이션을 만들며 멀티 플랫폼을 지원하는 서비스의 경우 다이얼로그의 버튼 위치를 어떻게 설정할 것인가에 대해 잠깐 고민했었다.
내가 고민한 이유는 Mac과 Windows의 기본 가이드라인에서는 버튼의 위치가 반대이기 때문이다.
OS의 가이드라인을 따를 것인가, 서비스에 통일감을 줄 것인가...?
결국 우리 서비스는 UI 통일감을 선택했다. 두 가지 OS 이외에도 고려해야할 플랫폼이 더 존재하기 때문이고, 멀티 디바이스를 넘나들며 동일한 사용자경험을 주는 것이 서비스 특징이기 때문이었다.
당연한 것은 없다는게 UX의 어려운 점이고, 모든 것엔 이유가 있다.
위의 스크린샷은 타사의 어플리케이션을 살펴본 사례이다.
웨일의 경우 Windows 사용자가 더 많았던걸까? 에버노트는 그 반대일까?
+ 웨일 프로젝트에 참여하신 분이 친절하게 댓글을 남겨주셔서 덧붙이는 글
혹시 본인처럼 멀티플랫폼/디바이스를 지원하는 프로덕트를 준비하며 고민하는 분이 있다면 도움이 될까싶어서 당시 웨일팀에서 진행했던 문제 해결과정에 대해 정리해본다.
아래와 같은 문제 해결 과정으로 웨일의 다이얼로그 버튼 위치가 정해졌다고 한다.
서비스 제작 초기 웨일팀에서 고민한 문제
1. 윈도우,맥,리눅스,아이폰,안드로이드 5개 플랫폼에 통일성을 유지할 수 있을까?
2. (크로미움 오픈소스를 바탕으로 만들어서) 크로미움에서 띄우는 다이얼로그도 많은데 그걸 강제로 다 바꾸는게 의미가 있을까?
고민 끝에 세운 원칙
1. 되도록 OS 정책을 따른다.
- 한꺼번에 윈도우와 맥을 사용하는 사람은 많지 않고,
- 웨일끼리 통일성을 유지해서 전환 코스트를 줄이는 것 보다, 웨일과 다른 서비스간 통일성이 깨져서 생기는 문제가 더 크다고 판단
2. 크로미움 그대로 사용하는 기능의 다이얼로그는 크로미움을 따른다.
- 이걸 고치면 향후 들어가는 비용이 더 커짐
3. 어디에도 해당하지 않으면 모바일 친화적인 방향으로 한다.
- 웨일 데스크탑과 모바일간 통일된 경험 고려
결론은 프로세스 및 원칙은 프로젝트의 방향을 설정하는데에 중요하다는 점이며, 이건 단지 다이얼로그 버튼만의 문제가 아니라 이후 진행 중 발생하는 모든 의사결정에서 중요한 기준이 될 것이기 때문이다. 수많은 참여자와 다양한 의견이 있을 때에 특히 명확한 가이드는 중요한 역할을 한다.
아래에는 관련해서 작성된 아티클을 번역해서 공유한다.
클래식한 자료라서 조금 오래되었지만 올리기로 한다.
우리는 전반적인 사용자 경험에 그다지 중요하지 않아보이는 UI 디자인의 디테일에 대해 많은 질문을 받습니다. 그 중 한가지 클래식한 질문은 Dialog Box의 버튼 순서입니다.
확인(OK or Comfirm) / 취소(Cancel)
취소(Cancel) / 확인(OK or Confirm)
둘 다 합리적인 선택이며, 사람들은 아마 본인의 선호도에 관해 몇 시간동안 논쟁도 가능할겁니다.
1. 확인(OK)버튼을 먼저 두는 경우
확인(OK)버튼을 먼저 두는 경우에 왼쪽에서 오른쪽으로 글을 읽은 영어 및 기타 언어의 자연스러운 읽기 순서를 지원하게 됩니다. 다른 버튼 세트마다 자연스러운 진행 방식을 가집니다. 예를 들면, 예/아니오(Yes / No)나 이전/다음(Previous / Next )같은.
읽기의 순서가 논리적 순서와 일치하도록 항목을 나열합니다. 그리고 사용자가 '취소'보다 확인을 먼저 사용한다면 이 순서로 배치하는 것이 좋습니다.
2. 확인(OK) 버튼을 나중에 두는 경우
확인 버튼을 마지막에 나열하면 대화상자의 결론이 확인으로 종료되기 때문에 흐름이 향상됩니다.
또한 이전/다음 처럼 확인은 사용자를 앞으로 전진시키는 선택이고, 취소는 사용자를 뒤로 보내는 선택이라고 설명한다면 확인(OK)는 오른쪽의 다음(Next)과 같은 위치에 배치되어야 합니다.
이와 같은 경우에는 당신이 무엇을 하든 상관없을 때가 많습니다. 어느 쪽을 선택하든 합리적인 이유가 있으며 선택의 여지가 없다고 해서 사용성에 재앙을 초래할 가능성은 없습니다.
특정 상황에서 "올바른" 선택을 선택하면 일부 사용자는 0.1초를 절약할 수 있지만 그 선택이 무엇인지 알아내기 위해 충분히 정교한 조사를 수행할 정도의 가치는 없습니다. 핵심 성과 지표를 83%이상 변경할 수 있는 항목에서나 사용성 리소스를 사용하는 것이 좋습니다.
따라서 이 특정 선택을 하려면 애플리케이션 디자인의 다른 많은 디테일한 선택과 마찬가지로 플랫폼 GUI 표준을 따르는 것이 가장 좋습니다. 사용자 기대치를 따르는 일관된 디자인을 적용하면 애플리케이션에 약간 더 적합할 수 있지만 사용성에 불일치가 발생하는 작업을 수행하는 것보다 훨씬 더 많은 시간(그리고 더 많은 실수)을 절약할 수 있습니다.
불일치는 절약하는 것보다 더 많은 시간을 소비합니다.
표준에서 벗어나면 사용자가 UI 요소를 간과하거나 오용하기 때문에 몇 분 또는 몇 시간의 비용이 쉽게 듭니다. 사람들이 불일치에 대해 숙고하는 데 보내는 시간은 일반적으로 전문화된 설계를 통해 얻을 수 있는 작은 절감액보다 훨씬 더 많습니다.
안타깝게도 Windows 사용자 경험 가이드 라인은 확인/취소 버튼의 순서와 관련 하여 Apple 휴먼 인터페이스 지침과 다릅니다.
Windows에서는 '확인'을 최우선으로 합니다.
애플은 '확인(OK)'를 마지막에 둡니다.
다음 두 가지 PC 플랫폼 중 하나를 위한 데스크톱 애플리케이션을 설계하는 경우는 선택이 쉽습니다.
플랫폼의 가이드라인을 따르면 됩니다.
덧붙임.
아래 내용의 경우에는 해당 아티클대로 번역하긴했지만, 모바일 애플리케이션들이 나오기 이전에 작성된 글이라는 점을 감안해야한다. 작성되는 시점 OS의 사용비율은 Windows가 80% 이상을 차지했기 때문에 일반적인 웹 애플리케이션의 다이얼로그도 '확인-취소' 의 순서로 배치된 것이다. 사람들이 글을 읽을 때 혹은 질문할 때 맥락상 긍정-부정의 순서로 먼저 물어보는 것과 같은 원리인 것이다.
하지만 iOS와 안드로이드를 거쳐 모바일 애플리케이션이 생겨나면서부터는 취소-확인이 일반적인 경향으로 자리잡았다. 그 이유는 첫번째 설명했듯이 결론적으로 '확인'을 눌러야 하기 때문에 시선이 확인-취소-확인으로 흐르기보다는 취소-확인으로 결론나는 것이 효율적이라고 판단했기 때문이다.
현재 적용되는 대체적인 방향은 Positive하거나 사용자가 실제로 행동해야하는 내용이 담긴 명시적인 버튼을 마지막에 두는 경향이 있다. 단순히 '확인'보다는서비스에서 사용자의 행동을 유도하고자 하는 버튼명을 작성해야한다. (모바일의 경우 별도로 다른 아티클을 참고해보는 것도 좋겠다.)
Dialog Buttons for Web-Based Apps (웹 기반 앱용 대화상자 버튼)
웹 기반 애플리케이션을 설계하는 경우에는 결정을 내리는 것이 더 어렵지만 대부분의 사용자가 선호하는 플랫폼을 선택하는 것이 좋습니다. 서버 로그에서 특정 웹사이트 또는 인트라넷에 대한 Windows 및 MacOS 사용자의 비율을 보여줍니다.
물론 Windows에는 일반적으로 더 많은 사용자가 있으므로 로그를 확인하는 것이 귀찮다면 대부분의 상황에 적용되는 지침은 다음과 같습니다.
먼저 확인 그리고 취소의 순서 (Office 2007의 이 스크린샷과 같이)
스크린샷은 대화 상자 버튼에 대한 두 가지 추가 가이드를 설명합니다.
일반 레이블('OK'와 같은) 일반적인 라벨을 사용하는 것보다는 버튼의 기능을 설명할 수 있는 버튼명을 지정하는 것이 더 좋습니다. 명시적 라벨은 적시에 도움말 역할을 하므로 사용자는 올바른 행동을 할 수 있게 됩니다.
가장 일반적으로 선택되는 버튼을 기본값으로 하여 강조 표시합니다.(특별히 위험한 액션이 있는 경우는 제외합니다.이 경우 사용자는 Enter 키를 눌러 실수로 선택하지 않고 버튼을 명시적으로 선택하기를 원합니다.
그리고 관련이슈로 정리된 다른 글
