왜 정리했지?#

UI를 만들다 보면 이런 말을 자주 합니다.

“이게 더 깔끔한 것 같은데?”

“이쪽이 더 보기 좋습니다.”

“버튼이 조금 이상한 것 같습니다.”

저도 이런 말을 합니다. 디자인을 보자마자 이상하다는 느낌은 드는데, 막상 뭐가 이상한지 설명하려고 하면 말이 길어집니다. 버튼이 큰 건지, 색이 강한 건지, 위치가 이상한 건지. 일단 마음에는 안 드는데 이유를 제대로 못 짚는 거죠.

혼자 작업할 때는 마음에 들 때까지 바꾸면 됩니다. 그런데 여러 명이 같이 리뷰하기 시작하면 문제가 생깁니다. 저는 여백이 부족하다고 하는데 다른 사람은 정보가 한눈에 보여서 좋다고 합니다. 둘 다 자기 입장에서는 맞는 말입니다. 그래서 결론이 안 납니다.

이대로는 계속 취향으로 싸우겠다 싶어 디자인을 평가할 때 같이 볼 수 있는 기준을 정리하기 시작했습니다.

예쁘면 다 된 줄 알았지#

예쁜 디자인은 좋습니다. 저도 예쁜 거 좋아합니다. 그런데 화면이 아무리 예뻐도 사용자가 버튼을 못 찾고, 저장됐는지도 모르고, 오류가 나면 처음부터 다시 해야 한다면 문제가 있습니다.

반대로 기능만 잘 돌아간다고 끝나는 것도 아닙니다. 글자가 안 보이거나 특정 사용자가 조작할 수 없다면 그것도 좋은 경험이라고 하기는 어렵습니다.

그래서 평가 기준을 다섯 가지로 나눴습니다.

• Usability: 사용자가 목표를 제대로 달성할 수 있는가?
• Visual Design: 정보의 중요도와 관계가 눈에 들어오는가?
• Interaction: 행동했을 때 예상할 수 있는 반응이 돌아오는가?
• Accessibility: 이용 조건이 다른 사용자도 사용할 수 있는가?
• Consistency: 한번 배운 규칙이 계속 통하는가?

디자인 평가의 절대 기준이 아닙니다. 일단 리뷰할 때 어디부터 봐야 할지 정해놓은 겁니다. 다섯 가지가 깔끔하게 나뉘지도 않습니다. 실제로 보면 하나의 문제가 여기저기 걸칩니다.

Usability: 일단 목적은 달성해야..#

가장 먼저 보는 건 사용성입니다. 사용자가 이 화면에 들어온 이유를 제대로 해결할 수 있는지 봅니다.

정보 하나 수정하려는데 화면 세 개를 거쳐야 하고, 이미 입력한 내용을 또 적어야 하고, 마지막에 오류가 나면서 전부 날아간다면 사용성이 좋다고 하기는 어렵습니다. 화면이 아무리 예뻐도 다시 입력하는 순간부터는 예쁜 게 눈에 안 들어옵니다.

확인할 내용은 이렇습니다.

• 사용자가 무엇을 해야 하는지 바로 이해할 수 있는가?
• 주요 기능을 쉽게 찾을 수 있는가?
• 불필요하게 반복하는 단계가 없는가?
• 실수하기 쉬운 부분을 미리 막아주는가?
• 오류가 발생했을 때 원인을 알고 복구할 수 있는가?
• 익숙해진 사용자가 반복 작업을 빠르게 처리할 수 있는가?

여기서 주의할 게 있습니다. 단계가 적다고 무조건 좋은 건 아닙니다.

클릭 수를 줄이겠다고 삭제 버튼을 누르는 즉시 모든 데이터를 지워버리면 빠르기는 합니다. 아주 빠르게 사고가 납니다. 이런 작업에서는 확인 단계가 필요합니다. 김유찬은 이걸 한번 뼈저리게 겪어보았습니다.

결국 봐야 하는 건 단계의 개수만이 아니라 그 단계가 왜 필요한지입니다. 목적 없는 단계는 줄이고, 사용자를 보호하는 단계는 남겨야 합니다.

Visual Design: 뭘 봐야 하지?#

시각 디자인에서는 정보가 어떻게 보이는지 확인합니다. 크기, 색상, 여백, 정렬 같은 것들입니다.

중요한 정보니까 크게 만들고, 이 버튼도 중요하니까 진하게 만들고, 저 안내도 놓치면 안 되니까 빨간색을 넣습니다. 그렇게 하나씩 강조하다 보면 화면 전체가 저를 부르고 있습니다. 정작 어디부터 봐야 할지는 모르겠습니다.

그래서 정보의 중요도와 시각적 강조 수준이 맞는지를 봐야 합니다.

• 중요한 정보가 먼저 눈에 들어오는가?
• 핵심 정보와 부가 정보를 구분할 수 있는가?
• 관련된 요소가 하나의 그룹으로 보이는가?
• 여백이 요소 사이의 관계를 설명하는가?
• 정렬 기준이 명확한가?
• 화면의 표현 방식이 서비스의 목적과 어울리는가?

여백도 무조건 넓히면 되는 게 아닙니다. 관련된 요소 사이를 너무 벌리면 서로 다른 정보처럼 보이고, 전부 붙여놓으면 어디까지가 한 묶음인지 알 수 없습니다.

“여백이 좀 이상합니다”라고 느꼈다면 거기서 한 번 더 들어가야 합니다. 어떤 요소의 관계가 잘못 보이는지까지 설명해야 실제로 수정할 수 있습니다.

Interaction: 된건가?#

저장 버튼을 눌렀습니다. 아무 일도 안 일어납니다.

저장이 된 건지, 아직 처리 중인 건지, 제가 버튼을 제대로 못 누른 건지 모르겠습니다. 그래서 한 번 더 누릅니다. 그래도 반응이 없으면 또 누르겠죠.

이런 상황을 확인하는 게 인터랙션 평가입니다. 사용자의 행동과 시스템의 반응이 제대로 연결되는지를 봅니다.

• 조작할 수 있는 요소가 명확하게 보이는가?
• 누르기 전에 어떤 결과가 나올지 예상할 수 있는가?
• 조작했을 때 적절한 피드백이 돌아오는가?
• 처리 중인지, 완료됐는지, 실패했는지 구분할 수 있는가?
• 원하는 요소를 정확하게 누르거나 조작할 수 있는가?
• 실제 결과가 사용자의 예상과 일치하는가?

모든 처리가 즉시 끝날 필요는 없습니다. 시간이 걸리면 걸린다고 알려주면 됩니다. 입력을 받았다는 표시와 현재 상태만 있어도 사용자는 무작정 버튼을 다시 누르지 않아도 됩니다.

완료 화면만 만들어놓고 끝내면 중간 과정이 비어버립니다. 로딩, 오류, 비활성 상태까지 같이 봐야 합니다.

Accessibility: 저는 잘 보이는데요#

제가 잘 보인다고 모두에게 잘 보이는 건 아닙니다. 제가 마우스로 문제없이 눌렀다고 누구나 그 기능을 사용할 수 있는 것도 아니고요.

오류가 났을 때 테두리를 빨간색으로 바꿨다고 해보겠습니다. 색을 구분할 수 있는 사람은 알아챌 수 있습니다. 그런데 그 색의 차이를 인식하기 어려운 사람에게는 아무런 안내도 없는 셈입니다.

접근성에서는 사용자의 능력이나 이용 환경이 달라졌을 때 막히는 부분이 없는지 확인합니다.

• 색상을 구분하지 못해도 정보를 이해할 수 있는가?
• 텍스트와 배경의 대비가 충분한가?
• 글자를 확대해도 내용이나 기능이 잘리지 않는가?
• 클릭하거나 터치할 영역이 충분한가?
• 키보드만으로 주요 기능을 사용할 수 있는가?
• 키보드로 이동할 때 현재 초점이 어디에 있는지 보이는가?
• 스크린 리더로 요소의 의미와 상태를 파악할 수 있는가?

여기에는 디자인 시안만으로 확인할 수 없는 항목도 있습니다. 버튼이 보기 좋게 그려져 있다고 키보드로 접근되는지는 알 수 없습니다. 스크린 리더가 어떤 이름으로 읽는지도 실제 구현을 봐야 합니다.

그래서 시안에서 확인한 것과 구현 후 검증할 것을 나누어 기록해야 합니다. 아직 확인하지 않은 항목을 문제없다고 처리하면 평가표만 멀쩡해집니다.

Consistency: 아까는 이거 아니었잖아#

어떤 화면에서는 연필 아이콘이 수정인데, 다른 화면에서는 새 글 작성입니다. 같은 기능인데 어떤 곳에서는 ‘저장’, 다른 곳에서는 ‘적용’, 또 다른 곳에서는 ‘완료’라고 합니다.

각각의 화면만 보면 그럴듯할 수 있습니다. 그런데 이어서 사용하면 계속 의미를 확인해야 합니다. 방금 배운 규칙이 다음 화면에서 안 통하는 겁니다.

일관성에서는 이런 부분을 봅니다.

• 같은 기능에 같은 이름을 사용하는가?
• 같은 의미의 요소가 비슷한 형태로 표현되는가?
• 같은 조작이 같은 방식으로 동작하는가?
• 화면 간 이동 방식이 일관적인가?
• 플랫폼에서 익숙하게 사용하는 관습을 따르는가?
• 기존 규칙과 다르게 만든 부분에는 이유가 있는가?

공통 컴포넌트와 디자인 시스템을 쓰면 관리하기 편합니다. 다만 같은 버튼 컴포넌트를 썼다고 일관성이 자동으로 완성되지는 않습니다. 이름도 다르고 동작도 다르면 생김새만 같은 겁니다.

반대로 화면의 목적이 다른데 배치까지 무조건 같게 만들 필요는 없습니다. 사용자가 익힌 의미와 동작의 규칙을 유지하는지가 중요합니다.

그래서 점수는!!!!!!!!!#

기준은 정했습니다. 그런데 평가 결과를 “사용성이 괜찮습니다”, “접근성이 조금 부족합니다” 정도로 남기면 나중에 비교하기가 어렵습니다.

조금 부족했던 게 얼마나 나아졌는지, 여전히 비슷한 상태인지 알 수가 없습니다. 그래서 각 축을 1~5점으로 평가하도록 했습니다.

점수	기준
5점	평가한 범위에서 사용자 경험을 저해하는 문제가 발견되지 않았습니다.
4점	경미한 개선점이 있지만 목표 달성에 미치는 영향은 작습니다.
3점	혼란이나 불필요한 지연을 만드는 문제가 있습니다.
2점	큰 혼란이나 반복적인 오류로 목표 달성이 어렵습니다.
1점	핵심 목표 달성을 막는 문제가 있습니다.

물론 숫자를 붙였다고 갑자기 객관적인 평가가 되지는 않습니다. 근거 없이 3점을 주면 그냥 제 기분을 숫자로 적어놓은 겁니다.

점수를 매기기 전에 누가, 어떤 목표로, 어떤 환경에서 사용하는지부터 정해야 합니다. 처음 사용하는 사람을 기준으로 평가했는지, 매일 쓰는 사람을 기준으로 평가했는지에 따라 판단이 달라질 수 있으니까요.

개선 전후를 비교할 때도 같은 조건을 적용해야 합니다. 점수 옆에는 발견한 문제와 그 점수를 준 이유를 같이 남깁니다. 확인하지 못한 항목은 ‘미평가’로 표시합니다.

또 태스크 유실#

사용성 3점이라는 결과를 받았다고 해보겠습니다. 이걸로는 어느 문제부터 고쳐야 할지 알 수 없습니다.

그래서 개별 문제에는 **심각도(Severity)**를 따로 기록합니다.

• Critical: 핵심 목표 달성 자체를 막는 문제입니다. 결제를 완료할 수 없거나, 특정 사용자가 주요 기능에 접근할 수 없는 경우입니다.
• Major: 목표 달성은 가능하지만 큰 혼란이나 지연을 만드는 문제입니다. 주요 기능을 찾기 어렵거나 오류를 복구하는 과정이 지나치게 복잡한 경우입니다.
• Minor: 목표 달성에 미치는 영향은 작지만 개선할 필요가 있는 문제입니다. 의미 전달에는 지장이 없는 문구의 어색함이나 미세한 정렬 차이 등이 해당합니다.

점수는 각 평가 축의 상태를 요약하고, 심각도는 개별 문제의 영향을 설명합니다.

수정 순서는 여기서 한 번 더 판단해야 합니다. 심각도를 중심으로 얼마나 자주 발생하는지, 누가 영향을 받는지, 우회할 방법이 있는지, 수정에 얼마나 시간이 드는지 함께 봅니다.

다만 영향을 받는 사용자가 적다고 핵심 기능이 막히는 문제를 가볍게 처리해서는 안 됩니다. 평균 점수가 높아도 누군가는 서비스를 아예 못 쓰고 있을 수 있습니다.

이거 아까 본 문제인데#

평가하다 보면 같은 문제가 여러 축에서 다시 등장합니다.

예를 들어 부가 행동 버튼이 핵심 행동 버튼보다 더 강하게 강조되어 있다면 시각 디자인에서는 강조 수준이 잘못된 문제입니다. 사용성에서는 사용자가 핵심 행동을 찾기 어렵게 만드는 문제일 수 있습니다.

그렇다고 평가표에 두 번 등록해서 문제 개수를 늘릴 필요는 없습니다. 하나의 문제에 관련된 축을 같이 적으면 됩니다.

• 발견한 문제: 부가 행동 버튼이 핵심 행동 버튼보다 강하게 강조되어 있습니다.
• 관련 평가 축: Visual Design, Usability
• 예상되는 영향: 사용자가 핵심 행동을 찾는 데 시간이 걸리거나 부가 행동을 먼저 선택할 수 있습니다.
• 개선 방향: 핵심 행동을 먼저 인식할 수 있도록 버튼의 강조 수준을 조정합니다.

여기서 ‘예상되는 영향’이라고 적은 이유도 있습니다. 제가 화면을 보고 그렇게 생각한 것과 실제 사용자가 그렇게 행동한 것은 다릅니다.

사용자 테스트에서 확인했다면 관찰한 사실을 적고, 아직 확인하지 못했다면 예상이라고 적어야 합니다. 그래야 나중에 무엇을 검증해야 할지도 알 수 있습니다.

이제 디자이너 부려먹을 시간~#

이 기준을 정리한 이유는 리뷰할 때 할 말을 늘리기 위해서가 아닙니다. 다섯 가지 축을 기준으로 보면 적어도 설명을 조금 더 구체적으로 할 수 있습니다. “버튼이 이상합니다”에서 “부가 행동이 더 강하게 보여서 핵심 행동을 찾기 어렵습니다”까지 갈 수 있는 겁니다. 그러면 수정할 대상도, 수정하는 이유도 분명해집니다.

기준이 생겼다고 의견 차이가 사라지지는 않습니다. 그래도 서로 어떤 근거로 이야기하는지는 확인할 수 있습니다. 판단이 갈리는 부분은 실제 사용에서 검증하면 되고요.

그러니 마음껏 디자이너에게 의견주세용. 여러분의 디자이너는 피드백을 사랑합니다.