윌 그랜트(2019). UX 원칙: 경험 많은 UX Writer의 원 포인트 레슨

저자는 오랜 시간 UX writer로서 여러 제품의 이용자 경험을 설계하고 이용자 테스트를 수행했던 경험이 있다. 그 경험을 바탕으로 굉장히 단정적이고 교조적인 문체로 글을 전개하고 있는데, 굳이 연구결과 등을 인용하지 않아도 그의 말은 충분히 설득력 있다. 왜냐하면 나 또한 제품 기획자이기 이전에 여러 제품의 이용자이기 때문이다. 그의 조언을 접하면 '그래 나도 이용할 때 그랬어'라는 공감이 된다.

아래는 책 본문에서 발췌한 내용.

#02 두 가지 이상의 서체(typeface)를 사용하지 마라

폰트는 소프트웨어에서 서체를 렌더링하고자 사용하는 파일을 말한다. 폰트가 팔레트에 있는 페인트라면, 서체는 캔버스 위에 그려진 명작에 해당한다.

• 최대 2개의 서체를 사용하라
• 하나는 제목 용도다
• 다른 하나는 본문 용도다

#03 사용자의 컴퓨터에 설치된 폰트를 사용하라

브랜드의 폰트는 아주 매력적이지만, 서버에서 다운로드되고 랜더링돼야 하므로 페이지를 로드하는 데 3초의 추가 시간이 소요된다.
폰트는 어디선가 로드되어야 한다. 이는 폰트 파일이 사용자 기기에 다운로드되는 데 추가적인 시간이 소요된다는 것을 의미한다. 콘텐츠가 가득한 페이지는 적절한 폰트 파일이 다운로드되고 랜더링되는 동안에 종종 깨져 보이게 된다. 이를 Flash of Unstyled Content 혹은 Flash of Unstyled Text라고 부른다.
대부분의 경우 시스템 기본 폰트를 사용하면 페이지를 더 신속하게 표시하고, 글자를 더 선명ㅎ게 만들며 가독성을 높여준다.

• 사용자가 이미 보유한 시스템 기본 폰트를 사요하라
• 시스템 폰트는 일반적으로 외부 포트보다 렌더링이 더 잘된다.
• 기본 폰트 사용은 페이지 로드 시간을 단축시킨다.

#04 글자 크기를 사용해서 정보 체계를 표현하라

• 글자 크기는 사용자에게 정보의 중요도를 보여 준다.
• 최소 2개, 하지만 3개는 넘지 않는 글자 크기를 사용하라.
• 사용자에게 어떤 정보가 가장 중요할지 생각하라.

#05 본문에는 합리적인 기본 크기를 사용하라

• 본문 글자 크기 16px, 줄 간격 1.5, 자간 ‘자동’ 혹은 ‘기본’은 안전한 선택이며, 사용자의 대다수에게 적절한 기본값이다.

• 사용자가 자신의 기기에서 글자의 크기를 키우거나 줄이는 것을 허용하라.
• 기기의 크기 조정 기능을 절대로 비활성화시키지 마라.

#06 줄임표를 사용해서 다음 단계가 있다는 것을 알려라

• 사용자가 추가적인 액션을 수행해야 할 경우, 줄임표를 표시하라.
• 줄임표는 액션을 확정하려면 추가 단계를 거쳐야 한다는 것을 알려 줌으로써 사용자에게 자신감을 줄 수 있다.
• 사용자는 줄임표가 사용자 인터페이스에서 어떤 의미가 있는지 무의식적으로 학습하게 된다.

#09 텍스트만이 아니라 버튼 전체가 클릭 가능하게 만들어라

• 버튼은 버튼처럼 보여지고 동작해야 한다. 버튼의 어떤 부분을 눌러도 작동해야 한다.
• 데스크톱에서 마우스를 버튼 위에 올리면 포인터가 손가락으로 바뀌게 만들어라.
• 버튼이 클릭되었다는 시각적 피드백을 사용자에게 제공하라.

#11 검색은 입력 필드와 ‘검색’이라고 적힌 버튼으로 구성돼야 한다.

• 검색은 입력 필드와 검색 버튼으로 구성돼야 한다.
• 검색 용도로는 ‘돋보기’ 아이콘만 사용하라
• 모바일에서 검색 탭이 선택되면 포커스를 검색 필드로 이동시켜라.

#12 슬라이더는 수량화할 수 없는 값에만 사용해야 한다

• 슬라이더 컨트롤은 구체적인 값을 설정하는 데 절대 사용해서는 안 된다
• 볼륨, 밝기처럼 정성적인 설정을 조정하는 데 슬라이더를 사용하라
• 슬라이더 컨트롤은 사용자의 포인팅 기기로 쉽게 잡을 수 있도록 적절한 크기로 만들어라.

#13 정확한 숫자를 위해서는 숫자 입력 필드를 사용하라

• 숫자 입력 컨트롤은 구체적인 숫자 값 설정에 사용돼야 한다.
• 브라우저 또는 기기가 최적의 입력 방식을 선택하게 하라. ‘당신만의’ 숫자 입력 컨트롤을 만들지 마라.
• 입력 폼은 사용자에게 콘텐츠 소비보다 더 많은 노력을 요구한다. 따라서 입력이 필요한 ‘항목’을 최소화하라.

#14 옵션이 많지 않다면 드롭다운 메뉴를 사용하지 마라

• 드롭다운 메뉴는 짜증을 유발할 수 있으므로 꼭 필요한 경우에만 사용하라
• 아주 긴 드롭다운에서는 검색 기능을 제공하라.
• 드롭다운은 모바일 앱에서 특화된 UI를 활용할 수 있으므로 유용할 수 있다.

# 17 피드 스타일의 콘텐츠에서만 ‘무한 스크롤’을 사용하라

• 긴 목록에서는 페이지 번호 매김pagination을 사용하라.
• 무한 스크롤은 뉴스 피드 스타일의 콘텐츠에서만 사용하라.
• 사용자가 피드에서 벗어날 때에는 사용자의 위치를 기억하라.

#18 콘텐츠에 시작, 중간, 끝이 있다면 페이지 번호 매김을 사용하라

번호가 매겨진 페이지 목록은 ‘구식’처럼 보이지만 몇 가지 주요한 이점을 가진다.

• 목표 지향적이므로 사용자가 목록에서 필요로 하는 항목을 찾으려고 한다. 페이지 번호 매김은 무한 목록에서 검색하는 것보다 직관적으로 보여진다.
• 사용자의 위치를 기억하며 현재 페이지를 표시한다.
• 콘텐츠의 시작, 중간과 끝을 전달한다.
• 스크롤 바를 사용해야 페이지를 탐색할 수 있으며, 원한다면 바닥글에도 접근 가능하다.
• 사용자에게 검색, 정렬 및 필터 컨트롤을 제공하라.

#19 무한 스크롤을 사용해야 한다면, 사용자의 위치를 기억하고 그곳으로 돌려보내라

종종 사용자는 ‘좋아요’를 누르거나 댓글을 달고자 무한 스크롤 피드를 벗어나게 된다 거기에서 ‘back’을 누르거나(데스크톱), 이전으로 스와이프하거나(iOS), ‘back’ 버튼을 사용한다(안드로이드).
Q. 이 때 사용자들은 어디로 가는가?

1. 무한 스크롤 피드의 최상단으로
2. 사용자가 벗어났던 지점으로

정답은 당연히 b)다.

• 사용자가 긴 목록에서 벗어난 경우 사용자의 위치를 기억하라.
• 사용자를 목록의 동일한 지점, 혹은 페이지 번호에서 동일 페이지로 돌려보내라.
• 가급적 사용자의 방향 감각을 흐트러뜨리지 마라.

#21 ‘시작하기’ 팁은 닫기 쉽게 만들어라

팁은 필수가 아닌 선택으로, 그리고 끄기 쉽게 만들어라. ‘온보딩 마법사’를 사용자가 한 번의 탭으로 닫을 수 있게 한다면 보너스 포인트를 얻게 될 것이다.

• 사용자가 온보딩 마법사를 쉽게 벗어날 수 있게 하라.
• 한 번의 액션으로 전체 튜토리얼을 건너뛸 수 있게 하라.
• UI에 대해 너무 자세히 설명하는 것을 피하라.

#22 사용자가 피드를 ‘새로고침’하면, 읽지 않은 가장 최신 항목으로 이동시켜라

트위터는 사용자에게 얼마나 많은 ‘트윗’이 쌓여 있는지를 보여 주지만, 사용자의 명백한 액션 없이느 피드를 강제로 바꾸지 않으며, 사용자가 원하는 경우에만 수동으로 ‘새로고침’을 지원한다.

• 사용자들을 그들이 왔던 지점으로 돌려보내라.
• 사용 중에는 피드를 ‘새로고침’ 하지 마라.
• 피드 사용 중에는 피드를 수동으로 ‘새로고침’하는 옵션을 제공하라.

#23 항목들을 ‘햄버거’ 메뉴 속에 숨기지 마라

닐슨노만그룹의 ‘햄버거 메뉴와 숨겨진 내비게이션이 UX 지표를 손상시킨다’에 따르면 햄버거 메뉴는 다음과 같은 문제점을 가져온다.

• 사용자의 검색 시간을 늦춘다.
• 태스크의 체감 난이도를 높인다.
• 태스크 완료 시간을 지연시킨다.

햄버거 메뉴를 대체 가능한 몇 가지 디자인 패턴은 다음과 같다.

• 뷰 하단 네비게이션: iOS 앱에서 널리 사용되며, 4~5개의 주요 기능을 하단 고정 메뉴에 담을 수 있고, 마지막 항목은 ‘펼쳐지게’해서 고급 도구에 접근 가능하게 만들 수 있다.
• 탭 내비게이션: 뷰 하단 내비게이션을 뒤집은 것으로 안드로이드 앱에서 주로 사용되며, 항목이 뷰 상단에 위치한다.
• 세로 유형: 내비게이션을 뷰 왼쪽으로 고정시키고 글자를 수직으로 위치시킨다. 모든 문제를 해결할 수는 없지만, 항목이 6~7개보다 적다면 햄버거보다는 이 편이 낫다.

#25 메뉴 항목을 하위 섹션으로 나눠서 사용자가 긴 목록을 기억할 필요가 없게 하라

• 사용자는 목록에서 대략 7개의 항목을 읽고, 처리하고 기억해 낼 수 있다.
• 7개가 넘어가면 사용자의 목록 사용이 힘겨워진다.
• 유사한 항목들을 섹션으로 묶어라.

#27 메뉴 항목을 바닥글이나 뷰 하단에 반복 배치하라

대부분의 모바일 브라우저는 앱 상단의 바를 탭핑하면 페이지를 위로 스크롤하는 단축키를 지원한다. 페이지 하단에 플로팅되는 ‘맨 위로 돌아가기’ 링크를 제공할 필요는 없다. 이는 공간 낭비다.
좋은 해결책은 페이지 바닥글에 주요 메뉴 항목을 반복하거나, 적어도 사이트의 인기 영역에 단축키를 추가하는 것이다.
모질라의 바닥글은 지나치게 어수선하지 않으면서 내비게이션 체계의 상위 레벨 섹션으로 이어지는 유용한 링크를 제공한다.

• 내비게이션 항목을 바닥글에 반복 배치하라.
• 바닥글을 ‘막다른 길’로 만들지 마라
• 적절하다고 판단되면 바닥글에서 검색 기능 제공을 검토하라.

#30 기존 아이콘으로 신규 아이디어를 표현하려고 하지 마라

새롭지만 쉽게 알아볼 수 있고, 실제 사물에 매핑 가능해야 한다.
검색 가능한 온라인 아이콘 디렉토리가 여럿 있으며(https://thenounproject.com/), 이러한 사이트에서 빠른 검색을 통해 다른 디자이너들이 콘셉트를 표현하고자 어떤 아이콘을 사용하는지 확인하는 일은 유용하다.

• 당신의 니즈에 맞는 아이콘이 이미 존재할 것이다.
• 신규 콘셉트에 기존 아이콘을 사용하지 마라.
• 오픈소스나 공개 도메인 아이콘이 이미 있는지 확인하라.

#31 아이콘 위에 텍스트를 쓰지 마라

아이콘을 텍스트 레이블과 함께 표시하는 것을 말하는 것이 아니다. 그것은 필수적이다. 내가 말하려는 것은 바로 아이콘 내부에 텍스트를 포함시키는 부끄러운 관행이다.
‘문자열’을 다른 언어로 옮길 수 있는데, 아이콘 내부의 텍스트는 번역되지 않으므로 사용자가 당황하게 된다.

• 아이콘 안에 텍스트를 포함시키지 마라.
• 아이콘 내부의 텍스트는 번역될 수 없으며 보조 기술로도 읽히지 않는다
• 텍스트 레이블을 아이콘과 함께 제공해야 하지만, 아이콘 내부는 아니다,

#32 항상 아이콘에 텍스트 레이블을 제공하라

사용자가 컨트롤을 바로 인지할 수 있게 돕는 시각적 힌트를 주고, 사용자가 클릭 혹은 탭 가능한 타깃을 제공한다는 아이콘의 본래 목적으로 돌아가자.
사용자는 당신의 제품 내에서 이 아이콘이 이 콘텍스트에서 어떤 의미인지를 이해하려면 텍스트 레이블이 필요하다.

• 항상 텍스트 레이블을 아이콘과 함께 표시하라.
• 모바일 버전에서 레이블을 숨기거나 가리지 마라.
• 독자적으로 제작한 아이콘은 사용자에게 좌절감을 주는 주요 원인이다.

#37 이메일 주소를 인증하려고 하지 마라

클라이언트 사이드에서 이메일 주소를 인증하는 것은 매우 간단했다. 약간의 자바스크립트만으로 도메인이 다음과 같은 형식인지 확인했다.
지금은 1,000개가 넘는 최상위 도메인을 갖고 있으며, 지속적으로 추가 중이다.
도메인 목록은 항상 변하고 수많은 예외 상황이 있으므로 이를 검증하기 위한 자바스크립트를 잘 작성해야 한다.
그저 입력 필드를 ‘이메일’ 입력으로 지정하고 브라우저와 기기에서 나머지를 처리하게 하라. 이메일에 원클릭 링크를 보내는 방법을 사용해서 서버 사이드에서 이 주소들을 검증할 수도 있겠다.

• 클라이언트 사이드에서 이메일을 인증하지 마라
• 당신이 이메일 주소를 수집 중인 것을 브라우저 혹은 기기에게 알려라.
• 원클릭 인증 링크를 사용해서 서버 사이드에서 이메일을 인증하라.

#38 명확한 요구가 없다면 사용자가 입력한 데이터를 절대 지우지 마라

• 명시적인 허락 없이는 사용자 입력 데이터를 지우지 마라
• 사용자의 시간을 존중하라
• 그들의 입장이 돼 봐라. 당신이라면 이 모든 내용을 다시 입력하고 싶은가?

#43 대소문자를 구분하지 마라

• 확실하지 않다면 대소문자 구분이 없는 것을 기본으로 하라.
• 비밀번호는 항상 대소문자를 구분하라.
• 대소문자를 구분해야 하는 경우에는 사용자에게 이를 알려라.

#44 좋은 폼 경험을 제공한다면, 사용자들은 당신의 제품을 사랑하게 될 것이다

• 필요 이상의 정보를 요구하지 마라
• 정보를 왜 수집하는지, 그리고 그 정보로 무엇을 할 것인지를 사용자에게 설명하라
• 폼에 필드를 추가할 때마다 전환율은 떨어진다.

#45 가능한 한 빨리 데이터 입력을 검증하라

클라이언트 사이드 검증이 항상 기술적으로 가능한 것은 아니지만, 어디서든 검증하는 것을 목표로 해야 한다. 서버로 ‘왕복’하고 돌아오는 것은 에러가 생겼을 때 답답하기 대문이다.
요즘에는 무엇이 틀렸는지 그리고 이를 바로잡고자 취할 수 있는 조치가 무엇인지를 사용자에게 보여줘야 한다.
사용자가 실수를 했다고 해서 절대로 폼 데이터를 지우지 마라

• 사용자에게 어디에서 실수했는지 가능한 한 빨리 보여 줘라
• 사용자가 폼을 제출할 때까지 기다리지 마라.
• 폼을 제출하기 전에 항상 검증할 수 있는 것은 아니지만, 목표로 삼기에 좋은 원칙이다.

#46 폼을 검증하지 못 한다면, 어떤 필드에 주의를 기울여야 하는지를 사용자에게 보여 줘라

• 서버 사이드 검증에서는 사용자가 피드백을 받기까지 딜레이가 발생하므로 그들이 콘텍스트를 기억할 수 있도록 도와라.
• 사용자에게 정확히 어떤 영역에 주목해야 하는지를 보여줘라
• ‘잘못된 것이 있습니다’와 같이 포괄적인 메시지는 피하라.

#47 너그러워져라 - 사용자는 어떤 데이터를 넣어야 하는지 모른다(그리고 신경도 안 쓴다)

• 데이터 입력 방식에서 사용자에게 융통성을 제공하라
• 기술적 어려움이 사용자에게 문제를 일으키지 않게 하라
• 사용자가 당신의 제품을 예상치 못 한 방식으로 사용할 수도 있다.

#56 소요 시간을 가늠할 수 없는 태스크라면 ‘스피너’를 보여 줘라

• 제품이 확실하게 진행 표시줄을 표시할 수 없을 때 스피너를 사용하라.
• 애니메이션을 사용해서 무언가가 벌어지고 있다는 것을 알려라
• 문제가 생기면 스피너를 멈추거나 제거하라.

#59 명암비는 당신 편이다

• 4.1:1의 명암비는 절대적인 최소치다.
• 7.5:1까지 명암비를 가져가는 목적은 가독성을 최대로 확보하기 위함이다.
• 많은 접근성 개선과 마찬가지로 이를 통해 모든 사용자가 개인의 능력에 상관없이 혜택을 본다.

#62 링크는 콘텍스트와 분리해도 의미가 통하게 만들어라

웹 링크를 사용자에게 제공하는 두 가지 방법 간의 차이점은 무엇인가?

1. 브로셔를 다운로드 받으려면: 여기를 클릭하세요.
2. 여기서 브로셔를 다운로드 받으실 수 있습니다.

a가 시각장애인이 사용하기에 더 어렵다

• 여기를 클릭하세요 링크는 피하라
• 콘텍스트와 관계 없이 의미가 통하는 서술적 링크를 사용하라.
• 이것은 접근성은 물론 검색 인덱싱에도 도움이 된다.

#64 컬러만 사용해서 정보를 전달하지 마라

• 정보를 전달하고자 컬러를 마음대로 사용하지 마라.
• 반드시 다른 지표를 컬러와 함께 제공하라
• 컬러는 여전히 사용자에게 중요한 부차적 정보의 출처다.

#67 컨트롤에 명확한 레이블을 적어라

• 시각 장애인이 스크린 리더를 이용할 수 있도록 레이블이 제공되어야 한다.
• 필드 레이블은 모든 사용자들에게 유용하다.
• 플레이스홀더 레이블은 사용자가 필드에 입력할 때 사라진다.

#71 사용자는 모든 여정에서 자신이 어느 단계에 있는지 항상 알아야 한다.

사용자가 현재 단계를 의식적으로 ‘이해’하진 않겠지만 적어도 대략적인 느낌은 가져야 하며 당신은 간단한 힌트를 통해 경험을 제공할 수 있다.
화면을 시각적으로 구분되게 만드는 것은 사용자가 내가 홈페이지로 돌아왔구나 하고 생각하는 데 도움을 줄 것이다. 이는 사용자의 통제력에 대한 전반적인 느낌에 기여하며 그들의 멘탈 모델을 강화시킨다.

• 제품의 랜드마크로 기능할 시각적 단서를 제공하라
• 모든 여전ㅇ에서 사용자의 현재 단계를 명확하게 알려라
• 사용자에게 단계간 이동이 가능한 콘트롤을 제공하라.

#72 이동 경로 내비게이션을 사용하라

• 이동 경로 내비게이션은 사용자의 자유로운 이동과 제품에 대한 이해를 돕는다.
• 모바일에서도 이동 경로가 필요한지 잘 생각해보라 - 항상 필요한 것은 아닐 수 있다.
• 이동 경로는 다수의 사용자들에게 잘 알려져 있다.

#79 당신의 파비콘을 독특하게 만들어라

• 파비콘을 알아보기 쉽고 독특하게 만들어라.
• 사용자들은 파비콘을 사용해서 탭, 즐겨찾기 등등을 확인한다.
• 파비콘은 16픽셀만큼 작은 크기로 표시될 수 있으므로 그 크기에서 점검하라.

#80 ‘기존에서 만들기’ 흐름을 추가하라

• 사용자가 시스템에서 기존 항목의 사본을 만들 수 있게 하라.
• 동일한 세부 사항을 매번 재입력하게 하지 마라.
• 이 패턴을 소비자 제품에도 적용하는 방법을 고민하라.

#82 검색 결과를 섹션으로 분류하라

• 검색 결과를 관련된 카테고리로 나눠라.
• 카테고리별로 항목 수를 표시하라
• 사용자가 다른 곳에서 접한 것과 동일한 검색 품질을 제공하는 것을 목표로 하라.

#84 말하지 말고 보여 줘라

• 사용자들은 텍스트를 거의 읽지 않으므로 말하고자 하는 바를 그들에게 보여 줘라
• 비디오 데모는 복잡한 소프트웨어와 UI에 아주 좋다
• 재방문 사용자가 데모를 건너뛸 수 있게 하라.

#85 용어를 일관되게 사용하라

• 제품 전반에서 일관된 용어를 사용하라
• 맘대로 레이블을 붙이지 마라. 당신의 제품을 위해 일관된 언얼ㄹ 개발하라.
• 일관된 카피를 사용해서 사용자가 보다 신속하게 멘탈 모델을 형성하도록 도와라.

#91 검색 결과 페이지 맨 위에 가장 관련성이 높은 결과를 표시해야 한다

왜 사용자에게 검색을 요청해놓고, 그들에게 형편없는 검색 결과를 보여 주는가?
이유1: 검색 알고리즘이 형편없다.
하지만 검증된 기술이 있으며(TF-IDF는 문서 랭킹에서 매우 유명한 알고리즘이다. term frequency inverse document frequency를 참고하라), 많은 기성 검색툴은 몇 가지 합리적인 기본값을 포함한다.
이유2: 필터 기본값이 형편없다.
검색 결과는 데이터베이스에서 적절한 순위로 반환되는데 당신이 잘못 선택된 필터를 적용하고 있을 것이다. … 적절한 기본값을 선택하고 사용자에게 기본값을 보여줘라. 그리고 그들이 마음대로 변경할 수 있게 지언하라.
이유3: 사용자에게 그들이 원치 않는 것을 팔려고 한다.
더 사악한 이유는 많은 사이트에서 당신이 보길 원하는 항목이 아니라 당신에게 보여 주고 싶은 항목을 제공한다는 것이다.

• 검색 결과 페이지 맨 위에 가장 관련성이 높은 결과를 표시하라
• 사용자가 검색 결과를 수정할 수 있도록 정렬 순서 및 필터와 함께 명확한 컨트롤을 제공하라
• 사용자처럼 생각하라 - 사용자가 어떤 결과를 제일 먼저 보면 좋을까?

#92 알맞은 기본값을 선택하라

• 당신이 선택한 기본 설정에 관해 신중히 생각하라
• 대다수의 사용사는 기본값을 절대 변경하지 않는다
• 기본값을 결정할 때 검색 용이성과 사용 빈도 사이에서 균형을 이뤄라

#95 기존 메타포를 기반으로 만들어라 - 이건 절도가 아니다

“사용자등은 대부분의 시간을 다른 사이트에서 보낸다. 이 말은 당신의 사이트가 그들이 이미 알고 있는 다른 사이트들과 동일하게 작동하길 원한다는 뜻이다”라고 서술한 제이콥의 인터넷 사용자 경험의 법칙(www.nngroup.com/videos/jakobs-law-internet-ux/)을 살펴보라

• 다른 제품의 우수 사례를 차용하는 것을 부끄러워 마라
• 사용자들은 그들이 이미 알고 써본 제품들처럼 당신의 제품이 작동하길 원한다.
• 이를 위해서는 이미 잘 알려진 패턴을 기반으로 만들어라

#96 인터랙션이 명확해야 하는지, 쉬워야 하는지 아니면 가능해야 하는지 결정하라

• 명확한: 예를 들어 카레라 앱에서 셔터 버튼 혹은 캘린더 앱에서 신규 일정 버튼처럼 앱에서 핵심 기능이다. 사용자가 제품을 쓸 때마다 매번 실행할 가능성이 높은 기능이며, 그 콘트롤은 쉽게 눈에 띄고 직관적이어야 한다.
• 쉬운: 예를 들어 쉬운 인터랙션이란 카메라 앱에서 전면과 후면 렌즈를 전환하거나 캘린더 앱에서 등록 일정을 편집하는 것이다. 컨트롤은 쉽게 찾을 수 있어야 하며, 메뉴 혹은 메인 컨트롤의 두 번째 레벨 항목에 위치한다.
• 가능한: 가능한 인터렉션은 거의 사용되지 않으며, 대개 고급 기능이다. 이것들은 발견될 수 있어야 하지만, 명확하거나 쉬운 인터랙션처럼 두드러질 필요는 없다.