웹유저빌러티(Web usability) - 상식이 통하는 웹사이트가 성공한다. 2판 - 독서요약

상식이 통하는 웹사이트가 성공한다 (2판) 국내도서>컴퓨터/인터넷 저자 : 스티브 크룩(Steve Krug) / 김지선역 출판 : 도서출판대웅 2006.08.10 상세보기

독서 계기

웹 기획자가 무엇을 하는 사람이며, 지녀야 할 기본소양이 무엇인지를 알아보았습니다.

그러다 보니 문뜩 웹 기획자가 웹사이트를 기획하는 사람이라면 그 웹사이트의 목적은 어디에 있으며, 성공과 실패는 무엇이 좌우 하는가 라는 의문에 들게 되었고 많은 고민을 하게 되었으나 참 심플한 답이 나왔습니다.

'아무리 하찮은 웹사이트라고 하여도 누군가 방문하여 보고 읽으며 사용하기를 바라기 때문에 만들어진다.'이런 단순한 결론 이었습니다.

그렇다면 지금 내가 알아야 할 것은 사용자가 쉽게 잘 사용할 수 있는 사용성(usability) 높은 사이트를 만들기 위한 기본 개념과 이론적인 지식이라는 생각이 들었습니다. ‘웹유저빌러티’에 타깃을 잡고 스터디를 시작한 것 입니다.

 

선별 계기

선별 기준은 ‘웹에 특화된 유저빌러티를 다루며 개념적이지만 쉽게 읽히는 책이며 높은 신뢰도를 지녀야 한다.’

신뢰도가 높아야 하는 이유는 저의 책 읽기 습관이 하나의 책을 길게 보고 문장 문장에 깊은 고민을 하는 형태이기 때문입니다.

당초 검색에 나오는 책도 많지 않았고 실제 오프라인 교보문고에서 찾아보아도 포괄적인 개념서로 그것도 개정판까지 나올 정도로 신뢰가 있는 책은 이 책이 유일했습니다.

이 책의 개정판은 무려 5년 만에 나왔음에도 거의 바뀐 것이 없을 정도로 대단히 정제된 책 이였습니다.

5년이 넘도록 읽히고 있는데 당연히 그만큼 웹유저빌러티의 본질에 닿아 있을 것 이다는 생각이 들었습니다.

 

요약

유저빌러티 디자인 원칙 

1장 사용자를 고민에 빠뜨리지 말자 
크룩이 제안하는 유저빌러티 제1법칙

• 사용자를 고민에 빠뜨리지 말자

  • 웹페이지에서 어떤 것이 제대로 전달되는지 그렇지 않은지를 결정할 때 가장 결정적이며 중요한 원칙입니다. 즉 명확해야 합니다
• 무엇이 사용자를 고민에 빠뜨리나
  • 버튼등 레이블이 관례적으로 명확해야 한다. (구인 광고를 보고 방문한 사용자가 '구인, 인재채용, 인사 관련' 링크 들을 보았을 때 같은 의미로 쓰일 수 있으나 결국 사용자는 고민한다.)
• 모든 것을 다 명확히 할 수는 없다
  • 명확하게 할 수 없을 경우에는 설명이나 주석을 활용하여 이해할 수 있도록 돕는다
• 명확히 하는 일이 왜 그토록 중요할까
  • 대부분의 사용자들은 사이트를 탓하기보다는 자기 자신을 탓하는 편을 택한다
• 그렇다면 어째서 그럴까
  • 예상과는 달리 대부분의 사람들은 웹페이지를 들여다 보는데 그리 많은 시간을 들이지 않기 때문이다

2장 실제로 어떻게 웹을 사용하고 있나 
훑어보다가 어느 정도 만족하면 대충대충 넘어간다

질문: 찾는 물건은 왜 맨 마지막에 나타날까?

답: 발견하는 순간 그만 찾으니깐. – 아이들의 수수께끼-

• 훑어보다가 어느 정도 만족하면 대충대충 넘어간다

  • 사용자들의 아이트랙킹 결과 http://www.hatena.co.kr/978
• 사용자는 웹페이지를 절대 ‘읽지’ 않는다
  • 대체로 사람들은 시간에 쫓깁니다
  • 모든 내용을 다 읽을 필요가 없다는 것을 알고 있습니다
  • 이미 훑어보기에 익숙해 있습니다
• 사용자는 최선을 택하지 않고 만족을 택한다
  • 사용자들은 찾고 있는 항목으로 연결해 줄 듯 보이는 링크를 발견하자마자 덥석 클릭할 가능성이 매우 큽니다
  • 비록 추측이 틀리더라도 피해가 크지 않습니다
  • 몇몇 선택사항을 심사숙고해 비교한들 그다지 나은 것도 없습니다
  • 어림짐작이 가져오는 재미가 의외로 쏠쏠합니다
• 전체를 살피기 보다는 대충대충 넘어간다
  • 작동 방식 자체는 사람들의 관심사가 아닙니다
  • 작동만 된다면 안주하게 됩니다
• 삶이 그대를 속일지라도…
  • 사용자들이 여러분의 웹사이트를 광고판처럼 여긴다면 아주 멋진 광고판을 만들어주면 되지 않겠습니까?

3장 광고 디자인으로부터 배운다 
훑어보기에 좋도록 디자인하는 법

• 명확히 눈에 띄는 계층구조로 만들어라

  • 중요한 내용일 수록 더욱 부각되도록 합니다
  • 논리적으로 연관된 항목들은 시각적으로도 연관되도록 표시합니다
  • 상위 항목은 하위 항목을 포괄하고 있듯이 시각적으로 표현합니다
• 익숙한 것이 편하다: 관례적 형식은 아주 유용합니다
  • 디자이너는 웬만해선 관례적 형식을 적용하길 꺼립니다
  • ‘여러분이 고안한 새 형식을 모든 사람들이 입을 모아 감탄할 만큼 훌륭하다고 평가하면 그때 과감히 새 형식을 적용하세요. 그렇지 않으면 기존의 익숙한 관례적 형식을 따르세요.’
• 페이지를 명확히 구분된 영역들로 나눠라
  • 사용자들이 웹페이지에서 주목해야 할 부분과 가볍게 무시해도 될 부분을 신속하게 판단할 수 있기 때문이다
• 클릭 가능한 항목인지 분명히 표시하라
  • 사람들이 웹에서 하는 동작 중에 상당한 비율을 차지하는 동작이 바로 ‘클릭할 항목을 찾아 다니는 동작’ 입니다
• 혼란스러울 요인을 없애라
  • 번잡함
  • 어수선한 주변환경
  • 웹페이지를 디자인 할 때에는 (혼란을 야기할 여지가 없다고 사용자를 통해 입증되기 전까지는) 모든 항목이 혼란을 줄 수도 있다고 가정하고 작업을 하는 편이 좋습니다

4장 동물입니까? 식물입니까? 무생물입니까? 
사용자들이 고민 없이 선택하길 좋아하는 이유

몇 번 클릭했는지는 중요치 않습니다.

클릭할 때마다 고민하지 않고 명쾌하게 선택하기만 한다면. – 크룩의 유저빌러티 제2법칙 -

• 대체로 사용자들은 클릭할 때마다 자신이 원하는 것을 향해 올바로 가고 있다는 확신만 흔들리지 않는다면, 수없이 클릭을 하더라도 크게 개의치 않습니다. 고민거리 없이 확신을 가지고 세 번을 클릭하는 행동은 심사숙고 끝에 한 번 클릭하는 행동과 맞먹는다고 하겠습니다
• 웹 페이지 구성요소(레이블 등)의 명확화
  

5장불필요한 단어는 삭제하라 
웹에서 말수를 줄이는 법

• 불필요한 단어는 삭제하라: 힘있는 문장일수록 간결하다
  • 문장 안에 불필요한 단어가 들어가서는 안 되며, 문단 안에는 불필요한 문장이 들어가서는 안 된다. 이는 그림 안에 불필요한 선이 있어서는 안 되고, 기계 속에 불필요한 부품이 들어가서는 안 되는 이유와 같다. – 윌리엄 스트렁크 주니어, 화이트의 ‘스타일의 구성요소’ -
• 입에 발린 미사여구를 없애라
  • 대부분의 웹 사용자들은 잡담이나 나눌 만큼 한가하지 않습니다. 곧바로 본론을 듣고 싶어합니다
• 장황한 설명 문구를 줄여라
  • 사용자들은 자기 나름대로 이것 저것 시도해 보다가 잘 안되면, 그 때가서야 설명서를 들여다본다는 사실입니다 
    

나무보다 숲을 보는 법 

6장 페이지 이름과 경로 표시 
네비게이션 디자인

• 동네 쇼핑센터에 갔을 때
  • 대부분 혼자 쇼핑센터 네비게이션 시스템을 통해 혼자 찾아보고 없으면 떠나거나 직원에게 물어본다
• 온라인 웹사이트를 찾아갔을 때
  • 일단 뭔가를 찾으려 합니다
  • 문의(검색)를 할지 아니면 혼자 찾아볼지 결정합니다
  • 검색중심의 사용자와 링크중심의 사용자가 있음
  • 브라우징을 하며 스스로 찾기로 했다면, 안내 표시를 참고하며 계층구조를 따라갑니다, 하지만 원하는 물건을 찾지 못할 경우 사이트를 떠납니다
• 참을 수 없는 브라우징의 가벼움
  • 규모를 짐작할 수 없다
  • 방향을 알 수 없다
  • 위치를 알 수 없다
  • 웹 네비게이션을 통해서 사이트의 계층구조를 구체적으로 표시해주거나 위치를 알려줌으로써 취약한 위치 감각을 보완해줍니다
• 네비게이션은 왜 필요한가
  • 의지할만한 버팀목이 되어줍니다
  • 무엇이 있는지 알려줍니다
  • 사이트 사용법을 알려줍니다
  • 사이트 제작자를 신뢰하도록 해줍니다
• 웹 네비게이션의 관례적 형식
  • 웹 네비게이션의 관례적인 형식들은 짧은 기간 내에 자리를 잡았는데 대부분은 기존의 인쇄  매체의 형식을 그대로 채택한 것이었습니다
  • 사이트ID 섹션
  • 하위섹션
  • 유틸리티
  • 현재 위치 표시
  • 페이지 이름
  • 로컬 네비게이션
  • 텍스트 방식 네비게이션
• 모든 페이지에 있다
  • 고정 네비게이션은 사용자들은 계속 같은 사이트에 들어와 있다는 확신을 줍니다
• 정말 모든 페이지에 있을까?
  • 홈페이지에서는 다른 모습일 수 있다.
  • 입력양식에는 고정 네비게이션을 초소화 할 수 있다
• 사이트ID, 혹은 분명히 여기가 삼천포는 아닌 증거
  • 사이트를 구성하는 논리적인 계층구조에서 가장 상위에 위치
  • 치장 혹은 사각 틀로 ID를 둘러싼다
• 섹션
  • 일명 기본 네비게이션
  • 사이트 계층구조에서도 상위 레벨을 차지함(1레벨 메뉴)
• 유틸리티
  • 사이트의 계층구조에 속하지는 않지만 사이트의 주요소로 연결되는 링크들
  • 네 개에서 다섯 개 정도가 적당함
• Home, Sweet Home!
  • 고정 네비게이션에서 가장 중요한 항목이라면 해당 사이트의 홈페이지로 연결해주는 버튼이나 링크입니다
• 검색방법
  • 사이트 내에 검색을 통해 뭔가를 찾을 만한 내용이 거의 없지만 않다면, 꼭 검색창을 달아두는 것이 좋다
  • 검색은 검색(search)혹은 페이지 이름이 검색(search)일 경우 찾기(go)를 사용한다
  • 도움말은 필요 없다
  • 검색옵션을 추가하여 얻을 수 있는 이점을 꼽아봐야 신통한 게 별로 없습니다
  • 아마존의 성공요인 중 하나는 검색옵션이 없는 강력한 통합검색능력.
• 2단계 3단계 그리고 그 다음에 오는 내용들
  • 웹 제작자와 디자이너들은 무엇보다 먼저 사이트를 구성하게 될 모든 단계의 네비게이션들을 예시해주는 샘플 페이지를 만드는 것이 중요합니다. 그런 다음에 홈페이지의 기본 색상에 대한 논의를 진행해도 늦지 않습니다.
• 페이지 이름, 혹은 L.A. 에서 드라이브하기 좋은 이유
  • 모든 페이지에는 고유의 이름이 있어야 합니다
  • 페이지 이름은 적당한 위치에 있어야 합니다
  • 페이지의 이름은 눈에 확 띠어야 합니다
  • 페이지 이름과 클릭한 내용은 일치해야 합니다
• 현재 위치
  • 디자인을 이유로 표시를 너무 흐리게 하지 않는다
• 경로 표시, 혹은 빵 부스러기
  • 최소한 계층구조 중에서 상위 두 단계 정도는 사이트의 어느 페이지에서든 보여주는 것이 좋은데, 경로 표시만 가지고는 이런 역할을 대신하지 못합니다
  • 최상단에 배치하세요
  • 각 단계 사이에 기호를 사용하세요
  • 작은 폰트를 사용하세요
  • 마지막 항목은 볼드체를 사용하세요
  • 경로 표시를 페이지 이름 대신에 사용하지는 마세요
• 탭이 좋은 4가지 이유
  • 명확합니다
  • 웬만해선 놓치기 힘듭니다
  • 깔끔합니다
  • 물리적인 공간과 같은 느낌을 줍니다
• 트렁크 테스트를 해보자
  • 사이트를 인쇄하여 빠르게 사이트 ID, 페이지 이름, 섹션, 로컬 네비게이션, 현재위치 표시, 검색방법을 체크

7장 홈페이지는 디자이너의 전유물이 아니다 
홈페이지 디자인

• 홈페이지 디자인
  • 사이트로고와 태그라인
  • 사이트계층구조
  • 검색
  • 관심끌기
  • 수시로 업데이트되는 컨텐츠
  • 제휴
  • 빠른 연결
  • 회원등록
  • 사용자가 찾는 것을 보여줘야 합니다
  • 사용자가 찾고 있지 않은 것도 보여줘야 합니다
  • 어디서 시작해야 하는지 알려줘야 합니다
  • 신용과 신뢰를 쌓아야 합니다
• “그런데 한 가지 조건이 더 있는데요, 눈을 가리셔야 합니다.”
  • 사용자는 일부만 볼 뿐입니다
  • 사공(프로젝트팀의 이해관계)이 너무 많습니다
  • 오직 한 페이지 안에서 모두의 관심을 사로잡아야 합니다
• 나무를 보지말고 숲을 보라
  • 가장 먼저 ‘이 사이트가 어떤 사이트인지’가 명확히 들어나는지 확인합니다
  • 제작자들은 사이트의 정체에 대해 너무나 잘 알고 있어서 더 이상 첫 방문자의 관점에서 홈페이지를 바라보지 못하기 때문입니다
  • 홈페이지에서 숲을 제대로 보여주지 못했을 때 하는 뻔한 변명 5가지
    • 그럴 필요가 있을까요? 그런 건 너무 분명하잖아요: 홈페이지를 통해 이런 사실들을 분명히 파악하지 못하는 사람들이 있다는 점을 이해하지 못합니다
    • 사이트 설명이 자꾸 보이면 사용자들이 귀찮아하지 않겠어요?: 사이트에 들어갈 때마다 거의 반 페이지를 넘는 똑같은 설명문구를 보게 될까 봐서 사이트 방문을 피하는 사용자는 거의 없습니다.
    • 정말로 우리 사이트가 절실한 사용자라면 어떤 내용을 담고 있는지 알아낼 겁니다: “아하, 이게 바로 그거예요? 저는 늘 이 사이트를 사용해왔는데, 이게 그런 뜻인지는 정작 모르고 있었네요.”
    • 그래서 광고를 하는 거 아닙니까?: 광고 자체를 이해했더라도, 정말 사이트에 들어오지 않고서 관심을 유발시킨 내용이 정확하게 뭔지를 사용자가 기억해주리라 생각하는 건 오산입니다.
    • 처음 방문자를 위한 링크를 추가할 겁니다: 대체로 사람들은 혼자 힘으로 꾹 참으면서 이것저것 시도해보다가 정 안되겠다 싶을 때 가서야 도움말 링크를 클릭할 것이기 때문입니다. 하지만 클릭하기 전에 이미 사용자가 의욕을 잃고 혼란스러워 하는 상태로 만든다는 것이 문제입니다.
• 메시지는 군더더기 없이 전달하라
  • 사용자들이 어떤 사이트를 처음 방문했을 때 이 사이트에 대한 단서를 얻을 수 있으리라 기대하는 곳이 두 군데 있습니다.
    • 태그라인: 홈페이지에서 가장 노른자
    • 환영메시지: 짧지만 가장 중요한 설명으로 사이트의 성격을 표현합니다.
  • 필요하다면 공간을 충분히 할애하세요
  • 그렇다고 지나치게 많은 공간을 할애하지는 마세요: 아무리 많더라도 4개 이하
  • 환영메시지와 같은 의례적인 미사여구는 되도록 줄이세요
  • 어떻게든 꼭 사용자 테스트를 하세요
• 태그라인은 일단 잘 만들고 봐야 한다
  • 태그라인은 기업 전체의 성격을 드러내기 때문에 기업 이미지와 전략을 한눈에 파악할 수 있도록 해줍니다
  • 잘 작성된 태그라인은 분명하게 정보를 전달합니다
  • 잘못 작성된 태그라인은 모호합니다
  • 좋은 태그라인은 길이가 적당합니다
  • 훌륭한 태그라인은 차별성과 분명한 장점을 전달해 줍니다
  • 지나치게 평범한 내용의 태그라인은 무의미합니다
  • 잘 된 태그라인은 단정하고 활기차며 재치 있어 보이기도 합니다
• 삼척동자도 안다면 태그라인은 필요 없다
  • 이미 충분히 인구에 회자되는 사이트: 이베이, cnn, 네이버 등
  • 오프라인 시장에서 이미 잘 알려진 사이트
• 어디부터 시작할지 분명히 보여줘야 한다
  • 검색하려면 여기서 시작하다
  • 브라우징을 하려면 여기서 시작한다
  • 이 사이트의 전략제품(혹은 컨텐츠)의 샘플이 필요하면 여기서 시작한다
• 홈페이지 네비게이션은 다른 페이지에 비해 좀 튀어도 된다(he의견: 모바일 에서는 화면이 비좁음으로 다르게 디자인 하는 것이 유용하다. 사용자도 이해한다.고 생각된다)
  • 섹션표시
  • 다른 방향
  • 로고와 태그라인을 위한 충분한 공간 확보
  • 그러나 반드시 섹션들을 1. 똑같이 이름을 붙여서 2. 똑같은 순서대로 3. 똑같은 그룹으로 묶어야 합니다.
• 풀다운 메뉴, 사용해도 되나
  • 어쨌든 풀다운 버튼을 눌러야만 합니다
  • 훑어보기 어렵습니다
  • 조작이 어렵습니다
  • 대부분의 경우 풀다운 메뉴는 장점보다는 단점이 더 많다고 생각합니다.
• 황금알을 얻을까, 거위고기 맛을 볼까
  • 홈페이지에서 모든 것을 다 부각시키려는 경향
  • 공유지의 비극: 같이 쓰는 페이지인 만큼 서로 자신들의 링크를 홈페이지에 밀어 넣으려 한다.
  • 다른 페이지들끼리 서로 연결하여 접속을 유도하거나 정기적으로 홈페이지의 같은 공간에 여러 페이지들을 돌려가며 노출하는 등의 방식을 적용해 트래픽을 골고루 유도해야 합니다.
• 직접 판단해보자
  • 사이트 예시에서 사이트의 핵심과 어디서 시작해야 할지를 찾는다.

 

상대를 이해하는 법 

8장 디자이너가 개발자를 만났을 때 
웹개발팀의 유저빌러티 회의가 대부분 시간낭비인 이유 그리고 그것을 방지하기 위한 대책

• “모든 사용자들은 ______을 좋아합니다.”
  • 웹 사이트 프로젝트 팀의 인원들은 웹 사용자들 대부분이 자신과 비슷하다고 생각합니다
• 농부 vs. 목동
  • 디자이너들은 시각적으로 매력을 끄는 사이트를 좋아한다
  • 개발자들은 근사한 기능들이 많은 사이트를 좋아한다
  • 그러나 교섭 문화권과 기술 문화권이라고 불렀듯이 디자이너와 개발자도 교섭문화권(경영, 마케팅, 비즈니스)의 무모한 약속 앞에서는 대부분 일방적으로 명령을 받으며 아주 가끔 뭉쳐 싸우게 됩니다.
• 평균 사용자라는 환상
  • 어디에도 ‘평균 사용자’란 존재하지 않는다는 겁니다. “모든 웹 사용자들은 다 제각각이다. 그리고 웹 사용방식은 기본적으로 모두가 특이하다”
  • 사용자들을 유심히 관찰하고 각자의 의도, 동기, 사고과정을 살펴보고 복잡다단한 양상을 모두 고려해야 비로소 탁월한 디자인이 나옵니다
• 종교논쟁을 방지하는 대책
  • “많은 사람들이 풀다운 메뉴를 좋아할까요?” 라는 질문은 질문 자체가 틀렸다. “이 페이지의 이런 맥락에서 이런 항목들과 이런 표현방식을 사용한 이 풀다운 메뉴는 이 사이트를 사용하는 많은 사람들에게 괜찮은 경험이 될까?”
  • 그때그때 구체적인 상황과 조건을 충분히 고려해야 한다는 것이죠
  • 그리고 결과는 직접 테스트 하여 내는 것이다.

9장 하루 1만원으로 유저빌러티 안심보험에 가입하자 
저렴하고 효과적인 유저빌러티 테스트를 수행하는 방법

• 포커스 그룹 테스트와 유저빌러티 테스트는 다르다
  • 포커스 그룹: 대개 5에서 8명 가량의 소그룹으로 모인 사람들이 탁자에 둘러앉아서 제시되는 아이디어나 디자인에 대해 이야기를 나눔. 어떤 사안을 두고 사용자들의 의견이나 느낌 등을 표본으로 신속하게 얻어내는데 효과적
  • 유저빌러티 테스트: 한 번에 한 사람의 사용자에게 테스트 대상을 보여주고 그 대상을 이해했는지 물어보거나, 그 대상을 이용해서 주어진 과제를 수행하도록 요구합니다. 이때 테스트 대상은 웹사이트 전체일 수도 있고, 사이트 샘플이나 페이지 샘플일 수도 있습니다.
  • 포커스 그룹은 사용자들이 무엇을 원하며 좋아하는지 결정하는 데 중요한 역할을 합니다
  • 포커스 그룹을 가지고는 사이트가 제대로 돌아가고 있는지 혹은 어떻게 사이트를 개선해야 할지 등의 문제를 알아내기는 힘듭니다
• 유저빌러티 테스트에 관한 몇 가지 진실들
  • 멋진 사이트를 만들고 싶다면 반드시 테스트를 하세요: 사이트를 구축하는데 골몰하다 보면 어느 순간 사이트를 새로운 시각으로 볼 수 없게된다.
  • 테스트는 자신이 살고 있는 동네에 타 지역에 사는 친구가 찾아온 상황과 비슷하다. 동네를 안내하다 보면 익숙해서 무심코 지나갔던 이모저모를 다시 보게 됩니다
  • 단 한 사람이라도 테스트 해보는 것이 전혀 안 해보는 것보다는 100배는 더 좋습니다
  • 프로젝트 말미에 50명을 데리고 테스트하느니 차라리 프로젝트 초기에 한 명을 데리고 테스트를 하는 편이 훨씬 낫습니다
  • 테스트에 참여할 사용자를 선발하는 절차 자체는 중요하지 않습니다
  • 테스트의 핵심은 증명하거나 반박하려는 것이 아니라, 제작 방향을 결정하는데 도움을 주기 위함입니다
  • 테스트는 반복이 중요합니다
  • 사용자의 반응을 직접 살펴봐야 합니다
• 저렴하면서도 효과적인 유저빌러티 테스트
• 테스트에 몇 사람이나 투입해야 하나
  • 테스트 한 회 당 이상적인 사용자의 수는 세 명이나 많아야 네 명
  • 테스트할 때마다 가능한 한 모든 문제를 뽑아내려는 것보다 가용 테스트인원을 나눠 여러 번 진행하면서 계속 문제를 추려내는 것이 훨씬 더 중요합니다
  • 보고서는 최소화 시키고 실제 문제를 해결하는 것에 주력한다.(회의를 통해 발견된 문제를 보고하는 방식)
• 테스트 인원 선발보다는 테스트 과정에 노력을 들이자
  • 알고 보면 우리 주위의 대부분은 웹 초보자랍니다
  • 주요 고객들에게만 꼭 맞게 사이트를 디자인한다는 생각은 그다지 바람직하지 못합니다
  • 사이트의 내용이 초보자들에게도 충분히 분명해 보일 정도라면 전문가들은 불편해할 이유가 없을 겁니다
  • 한 가지 유형의 사용자들만 거의 배타적으로 사용하는 사이트이고, 참가자들을 그런 집단에서 선발하는 것이 어렵지 않다면 그렇게 하세요
  • 고객들이 서로 분명하게 구분된 집단으로 나누어지고, 그 집단들이 각기 다른 관심사와 요구사항을 가지고 있다면, 각 집단 별로 사용자를 선별해 테스트를 해야합니다
  • 사이트를 사용하기 위해 특정 분야의 지식이 필요하다면, 최소한 한 번 정도는 그 분야의 전문 지식을 가진 사람들을 선발해서 테스트해야 합니다
  • 참가자들에게
    • 적절한 보상을 하세요
    • 선발 공고는 간단히 작성하세요
    • 테스트 사이트에 관해 미리 의견을 나누면 안 됩니다
    • 부담스럽게 생각하지 말고 친구나 이웃에게 부탁하세요
• 테스트를 어디서 해야 하나
  • 스크린 녹화 소프트웨어를 이용하여 테스트 PC에서 진행화면을 녹화하며 사용자와 진행자의 목소리를 녹음함
  • he의견: rview.net 서비스를 통해 회의실에서 원격 모니터하며 테스트PC에서 테스트를 진행. 녹화는 rviw와 테스트PC에서 이중 녹화
• 누가 테스트 진행을 해야 하나
  • 정말로 필요한 것은 해 보겠다는 용기
  • 인내심이 많고, 차분하고, 다른 사람과 쉽게 친해지며, 얘기를 잘 들어주고 공정한 사람을 골라보세요
• 누가 관찰해야 하나
  • 원하는 사람이라면 누구나
  • 회사차원에서 유저빌러티에 투자하도록 하기 위해서 경영진들이 단 한번만이라도 사용자 테스트를 관찰하도록 유도하는 것이 유용하다.
    • he생각: 한국적인 상황에서는 경영진의 고집이 실제 어떤 결과를 가지고 오는지 보여줄 수 있기도 할 것 같다
• 무엇을 언제 테스트해야 하나
  • 사이트 디자인을 시작하기 전부터, 경쟁사의 사이트를 테스트해 볼 필요가 있다(공짜로 작업모델을 만들어 준 것과 다름없다)
  • 전체식별 테스트
  • 과제부과 테스트
  • 디자인 아이디어를 사용자에게 보여주는 시점을 늦추지 않는 것이 좋습니다(사용자들은 미완성인 샘플을 보고 있을 때 개인적인 의견이나 취향을 말할 수 있다, 세부에 연연하지 않고 핵심사항이나 명칭에 집중하게 됨)
  • 칸막이 테스트
    • 새로운 유형의 페이지를 만들 때마다 그 페이지를 출력해서 옆에서 근무하는 동료에게 보여주고 그 페이지를 보고 이해할 수 있는지 여부를 알아보는 것
• 테스트 사례
• 즉시 결과를 검토하자
  • 옥석 선별
  • 문제해결
  • 지금 당장 수정할 수 있는 사항은 무엇이고, 다시 검토해봐야 할 사항이 무엇인지를 결정하는 것이 중요함
• 테스트 중 흔히 나타나는 문제
  • 사용자들은 개념에 어둡습니다
  • 사용자들이 찾는 단어는 없거나 다릅니다
  • 너무 많은 내용들이 넘쳐납니다
• 옥석선별 지침
  • ‘카약’ 문제는 무시하세요(사용자 스스로 문제를 해결하는 문제), 쉽고 분명한 것은 바로 수정.
  • (문제가 있는 항목에 대해)테스트항목을 더 넣으려고 하지 마세요 의미 전달을 방해하는 요소를 없애는 쪽이 훨씬 효과적임
  • 사용자가 새로운 기능을 제안하더라도 모두 수용할 필요는 없습니다. 사용자들은 정말 그 기능이 필요하다기보다 자신들이 좋아하거나 익숙한 기능을 요구하는 경향이 강함
• 목욕물은 버리되 아이는 버리지 말라
  • 변화를 줄 때마다 다른 부분에 영향을 주지 않을까 세심하게 고민해야 합니다
• 한 달에 딱 하루만 투자하자

 

외부 영향력을 수용하고 방어하는 법 

10장 품행이 방정해야 제대로 된 유저빌러티다 
왜 웹사이트가 품행 방정해야 하나?

정직함, 이게 어렵다.

만약 ‘거짓’으로 ‘정직’한 척할 수만 있다면, 나머지는 쉽다.

• “올바르게 행하라” 사용자를 존중할 줄 알아야 한다는 것
• 신뢰 저장소(사이트에 대한 사용자 개인의 신뢰도)
  • 신뢰저장소의 용량은 개인마다 다릅니다
  • 상황에 따라 다릅니다
  • 다시 채워질 수도 있습니다
  • 때로는 단 한번의 실수로 완전히 비워버릴 수도 있습니다
• 신뢰를 저버리는 것들
  • 사용자가 원하는 정보를 숨깁니다
    • 회사 전화번호, 배송요금, 가격
  • 사이트 운영자 자신들이 조금이라도 편하고자 사용자를 다그칩니다(전화번호 입력시'-'를 붙일지 땔지 같은 문제처리)
  • 꼭 필요하지도 않은 정보를 사용자에게 요구합니다
  • 사용자를 깔보고 속입니다
  • 사용자를 돕지는 못할지언정 훼방을 놓습니다
  • 사이트가 어수룩하게 보입니다
• 신뢰를 쌓는 것들
  • 사람들이 여러분의 사이트에 정말 바라는 것들이 무엇인지 알아야 하며, 그것들을 명확하고 쉽게 해야 합니다
  • 사용자가 무엇을 알고 싶어할지 사용자의 입장에서 생각해보세요
  • 사용자의 수고를 덜어줘야 합니다
  • 노력을 한 곳에 집중하세요
  • 사용자가 자주 하는 질문들을 파악해서 답변을 마련해 두세요
  • 사용자에게 한결 편리한 기능을 제공하려고 노력해야 합니다
  • 사용자가 오류를 신고하거나 스스로 복구할 수 있도록 해주어야 합니다
  • 문제를 해결할 수 없으면 일단 사과하세요

11장 액세서빌러티, CSS, 그리고 함께 사는 세상 
장애인과 노약자를 배려하는 웹사이트를 준비하려면

• 액세서빌러티: 장애인의 편의를 고려하는 유저빌러티
• 개발자와 디자이너가 의심하는 것
  • 옳은 일을 해라: 당신이 그 일을 했을 때 어떤 장애가 있는 부류의 사람들 생활이 얼마나 더 나아지는가를 설명해주는 것
• 디자이너와 개발자가 두려워하는 것
  • 일이 늘어납니다
  • 의견이 절충된 결과 어정쩡한 디자인이 나옵니다: 적극적인 디자인 아이디어가 필요하다
• 아직은 멀지만 가야 할 길
  • 액세서빌러티 검사기를 활용한다
  • 모바일 장치에까지도 확대되어야 한다
  • 미국-장애인-법과-웹웹-접근성-관심사와-오해-webaim-발표
  • 고령자ㆍ장애인 IT기기 접근성 높인다
  • 장애인차별금지법 해설
• 지금이라도 할 수 있는 다섯 가지 것들
  • 모든 사람들을 위한 유저빌러티 문제를 우선 해결하자
    • 장애가 없는 사람들도 사용하기 편리하게 유저빌러티를 잘 적용한 사이트일 수록, 장애가 있는 사람들이 사용하기에 편리한 사이트에 근접할 가능성이 커진다
    • 유저빌러티를 잘 적용하고 액세서빌러티 지침을 적용해야 한다
  • 필독 논문
    • 중략
    • 스크린리더 사용자는 그들의 귀를 통해 사이트를 훑어본다
      • 시각장애인들은 텍스트의 첫 줄이나 링크의 처음 시작 부분에 핵심단어가 없을 경우에는 결국 그 핵심단어를 놓칠 수밖에 없다
  • 필독도서. 생략
  • CSS를 사용하라
    • 스크린리더는 테이블 구조를 제대로 인식하지 못한다
    • 컨텐츠의 위치를 조작하기에 가장 좋습니다
    • 쉽게 변경시킬 수 있습니다
    • 브라우저가 다르더라도 외양을 유지할 수 있습니다
    • 컨텐츠를 순서대로 나열할 수 있습니다
    • 텍스트의 크기를 변경할 수 있습니다
  • 따기 쉬운 열매부터 따자
    • 모든 이미지에 적절한 대체 텍스트(alt text)를 추가합니다
    • 여러분이 작성한 폼(form) 요소들이 스크린리더와 제대로 동작하도록 해야합니다
    • 각 페이지마다 시작부분에 ‘메인 컨텐츠(로) 건너뛰기’를 넣는다(매번 등장하는 네비게이션을 건너 뛰도록 하기위해)
    • 키보드만으로 모든 컨텐츠에 접근할 수 있어야 합니다
    • 특별한 이유 없이 자바스크립트를 사용해선 안 됩니다
    • 서버 사이드 이미지맵이 아니라 클라이언트 사이드 이미지맵을 사용하세요

12장 저희 사장님이 이런 지시를 내리셨는데, 어떻게 해야 하나요? 
현명한 사람이 우매한 디자인을 강요받을 때

• 예외 없는 원칙은 없다
  • 아무리 나쁜 디자인 아이디어라 할지라도 적재적소의 상황에 충분히 공을 들이기만 한다면, 좋지 않은 효과를 상쇄할 뿐더러 도리어 좋은 아이디어라도 섬세하게 제대로 구현하지 못해서 효과를 발휘하지 못하는 경우가 있다는 사실을 알아야 한다
  • 상관의 나쁜 디자인 아이디어를 고집하는 것에 대해 배후에 숨은 좋은 의도를 이해해보려고 하는 자세가 거꾸로 여러분의 의견을 피력하는 가장 좋은 지름길이기도 합니다

 

 

독서후기

웹 기획에 있어서 가장 필요한 것은 아이디어다. 즉 웹사이트의 목적이다. 그 목적을 제외하고 가장 중요한 것을 뽑자면 유저빌러티가 아닐까? 책은 사용자가 선택하여 사용하는 웹사이트 서비스란 결국 사용자가 써 먹을 수 있게 만들어야 한다는 것을 역설하고 있다. 그것은 최소한 이고 오랫동안 사용자를 머무르게 하는 사이트는 사용자가 사이트의 이것 저것을 잘 사용할 수 있도록 해 주는 것이다 이 개념 자체가 유저빌러티이고 서비스 자체의 매력을 주는 것은 기발한 기능과 디자인과 같은 아이디어다. 일단 사용하게 만들고 좋게 만들자.

독서를 통해 나를 이렇게 뿌듯하게 해놓은 것을 보면 저자는 상식이 통하는 책을 만들었고 책 자체가 성공했다고 할 수 있을 것 같다. :)