IT/Book
소프트웨어, 누가 이렇게 개떡같이 만든거야 : 데이비드 플랫
SJ..
2008. 11. 16. 00:00
참 많이 찔려 가면서 본 책이다.
개발 하면서 시간과 사용자 사용성 사이에서 타협을 했고,
내가 이해하고 개발했기 때문에, 사용자들이 불편할꺼라는 생각도 못한적도 있었다.
최근 계속되는 유지보수를 하면서 짜증이 많이 난 상태였는데,
이 책을 보면서 반성하게 되었다.
앞으로는 정말 사용자 입장에서 이해하고, 유용한 서비스를 개발해야겠다고 다짐하게 되었다.
사용자의 편의성과 UI, 보안(웹페이지 회원 인증)에 대해 풍부한 사례와 해결방안을 제시한다.
분량으로는 책의 반정도 되고 내게 정말 유용한 부분이다.
그 후에 나오는 MS, 컴퓨터 괴짜, 앞으로의 대응에 대한 내용인데 앞부분에서 받은 인싸이트에 비해 좀 실망 스럽기까지 한다.
1. 사용자에게 시스템 이해를 강요하지 말고 간단하게 만들라.
실수가 발생 했을 때 이를 치료하는것이 훨씬 더 효율이다. 사용자의 확인(저장하시겠습니까? 취소하시겠습니까? 삭제하시겠습니까?)을 최소하 하고 최실행취소 & 재실행 기능을 사용하라. 실행 취소를 할 수 없는 작업에 대해서만 확인 대화상자를 띄워야 한다.
사용자 확인은 사용자에게 시스템 내부를 이해하고 이에따른 의사 결정을 맡기는 것이 된다.
60p - 고객은 드릴을 원하기 때문에 드릴을 구입하는 것이 아닙니다. 구멍을 내기 위해 드릴을 사는 것 입니다.
74p - 온갖 잡다한 것들을 가능하다는 이유만으로 사이트에 추가하는 데에만 정신이 팔려, 사용자들이 그런 것에는 관심도 없다는 것을 잊어버리는것 같다.
간단한 것을 간단하게 만드는 대신 복잡한 것들을 가능하게 만들고, 사용자의 사고 과정에 인터페이스를 맞추는 것이 아니라 사용자에게 내부 동작을 이해하도록 강요하는 것이다.
고객은 최소한의 노력으로 자신이 원하는 결과를 얻는데에만 관심이 있다.
2. 사용성 테스트 제대로 하자.
개발자는 이미 알고 있기 때문에 처음 접해보는 사람에게는 어려울 것이라는 것을 상상조차 하지 못한다.
102p - 디자이너들은 테스트가 필요하다는 것을 인식했을 때조차도 제대로 해내지 못합니다. 그들은 디자인을 자신들이 직접 테스트 하거나 또는 팀에서 같이 일하던 동료에게 부탁합니다. 놀랄 일도 아니지만, 테스트는 성공적으로 통과 합니다.
디자이너들은 사이트의 존재 목적과 기능을 이미 알고 있기 대문에, 그걸 모르는 사람들에게 사이트가 어떻게 비칠지를 상상할 시도조차 하지 못합니다. 그러나 새로운 방문자에게 수초 이내에 그걸 설명하는 것은 사이트 디자인에서 풀어야 할 가장 중요한 문제 입니다. 그렇게 하지 못할 경우 아무도 나머지 내용을 보지 않을 것이기 때문입니다.
디자이너는 네비게이션 기능이 일반 사용자에게도 쉬운지를 테스트 할 수 없습니다. 그들은 이미 사이트가 사용자로부터 데이터를 어떤 식으로 요구하는지 알고 있기때문에(신용카드 번호를 입력할 때 빈칸을 제거해야 한다는 식의), 일반 사용자가 그걸 생각해낼 수 있을지 장담 할 수 없습니다.
3. 보안은 사람과 관련된 문제다.
어떤 시스템의 보안 강도는 가장 약한 부분의 강도이다.
보안 관련 설정을 사용자에게 분담 시키지 말자. 어떤 기능의 설정 여부가 보안에 끼치는 영향을 잘 모른다.
117p - 컴퓨팅 분야의 거의 모든 문제와 마찬가지로 보안 또한 기술적 문제라기보다는 사람과 관련된 문제이다.
보안은 과정이지 제품이 아닙니다. 보안은 고리와 같아서 그 강도는 고리의 가장 약한 부분의 강도와 같다.
설계과정에서 인간의 본성을 인지하고 이해하고 고려하기 전까지는 사용자, 즉 인간이 항상 고리의 가장 약한 부분이고, 바로 이 부분이 고리가 끊기는 부분이 될 것이다.
138p - 대부분의 기능을 비활성화시켜 놓고 사용자가 필요한 기능만 활성화시켜 놓는 것이 모든 기능을 기본적으로 활성화시켜 놓고 사용자가 불필요한 것을 비활성화 시키도록 하는 것보다 훨씬 안전하다.
4. 인증 문제
각 인터넷 웹 싸이트마다 비밀번호 정책이 다르기 때문에 모든 싸이트의 비밀번호를 기억하기 힘들다.
그러면 매우 쉬운 비밀번호를 쓰거나, 적어 놓거나(사회 공학적 해킹에 취약) 하게 된다.
따라서 통합된 인증(현재 우리나라에서 은행에 상관없이 1개의 인증서를 등록해 사용 할 수 있는 것 처럼) 방법이 필요하다.
핵심 서비스가 아닌 부분을 아웃 소싱하듯 인증도 이런 방법이 필요하다.
171p - 개발자는 사용자의 삶을 쉽게 하기 위해 존재하기에 사용자가 아이다와 패스워드를 자유롭게 선택 할 수 있도록 해야 한다.
문자 선택의 제한을 두거나 강력한 패스워드를 요구하면 사용자는 패스워드를 적어 둘 것이고, 그러면 패스워드의 안정성은 포스트잇 수준으로 떨어진다.
5. 정확한 문제에 집중하자.
새로운 것을 만들 때 그것이 왜 유용하고, 왜 사용해야 하는지에 대해 고려하자.
기술만을 위한 기술을 사용하지 말고 풀어야하는 비즈니스 문제에 집중하라
238p - 괴짜는 문제 정의 기술, 즉 어떤 문제를 풀어나갈 것인지를 결정하는 방법이 부족하다.
240p - 괴짜는 사용 편의성이 모든 보안 시스템의 중요한 문제라는 것을 깨닫지 못한다.
유용한 싸이트
www.whysoftwaresucks.com : 이 책의 싸이트
www.webpagesthatsuck.com : 웹 디자인 전문가인 빈센트 플랜더스(Vincent Flanders)
참고 도서
Surely You're Joking, Mr. Feynman(파인만씨 농담도 잘 하시네1,2-사이너스 북스)
The Progress Rardox:How Life Gets Better While People Feel Worse - Random House, 2003
(진보의 역설 : 우리는 왜 더 잘살게 되었는데도 행복하지 않은가)
Cryptonomicon(크립토노미콘 1~4-책세상)
The Inmates Are Running the Asylum(정신병원에서 뛰쳐나온 디자인)
개발 하면서 시간과 사용자 사용성 사이에서 타협을 했고,
내가 이해하고 개발했기 때문에, 사용자들이 불편할꺼라는 생각도 못한적도 있었다.
최근 계속되는 유지보수를 하면서 짜증이 많이 난 상태였는데,
이 책을 보면서 반성하게 되었다.
앞으로는 정말 사용자 입장에서 이해하고, 유용한 서비스를 개발해야겠다고 다짐하게 되었다.
사용자의 편의성과 UI, 보안(웹페이지 회원 인증)에 대해 풍부한 사례와 해결방안을 제시한다.
분량으로는 책의 반정도 되고 내게 정말 유용한 부분이다.
그 후에 나오는 MS, 컴퓨터 괴짜, 앞으로의 대응에 대한 내용인데 앞부분에서 받은 인싸이트에 비해 좀 실망 스럽기까지 한다.
1. 사용자에게 시스템 이해를 강요하지 말고 간단하게 만들라.
실수가 발생 했을 때 이를 치료하는것이 훨씬 더 효율이다. 사용자의 확인(저장하시겠습니까? 취소하시겠습니까? 삭제하시겠습니까?)을 최소하 하고 최실행취소 & 재실행 기능을 사용하라. 실행 취소를 할 수 없는 작업에 대해서만 확인 대화상자를 띄워야 한다.
사용자 확인은 사용자에게 시스템 내부를 이해하고 이에따른 의사 결정을 맡기는 것이 된다.
60p - 고객은 드릴을 원하기 때문에 드릴을 구입하는 것이 아닙니다. 구멍을 내기 위해 드릴을 사는 것 입니다.
74p - 온갖 잡다한 것들을 가능하다는 이유만으로 사이트에 추가하는 데에만 정신이 팔려, 사용자들이 그런 것에는 관심도 없다는 것을 잊어버리는것 같다.
간단한 것을 간단하게 만드는 대신 복잡한 것들을 가능하게 만들고, 사용자의 사고 과정에 인터페이스를 맞추는 것이 아니라 사용자에게 내부 동작을 이해하도록 강요하는 것이다.
고객은 최소한의 노력으로 자신이 원하는 결과를 얻는데에만 관심이 있다.
2. 사용성 테스트 제대로 하자.
개발자는 이미 알고 있기 때문에 처음 접해보는 사람에게는 어려울 것이라는 것을 상상조차 하지 못한다.
102p - 디자이너들은 테스트가 필요하다는 것을 인식했을 때조차도 제대로 해내지 못합니다. 그들은 디자인을 자신들이 직접 테스트 하거나 또는 팀에서 같이 일하던 동료에게 부탁합니다. 놀랄 일도 아니지만, 테스트는 성공적으로 통과 합니다.
디자이너들은 사이트의 존재 목적과 기능을 이미 알고 있기 대문에, 그걸 모르는 사람들에게 사이트가 어떻게 비칠지를 상상할 시도조차 하지 못합니다. 그러나 새로운 방문자에게 수초 이내에 그걸 설명하는 것은 사이트 디자인에서 풀어야 할 가장 중요한 문제 입니다. 그렇게 하지 못할 경우 아무도 나머지 내용을 보지 않을 것이기 때문입니다.
디자이너는 네비게이션 기능이 일반 사용자에게도 쉬운지를 테스트 할 수 없습니다. 그들은 이미 사이트가 사용자로부터 데이터를 어떤 식으로 요구하는지 알고 있기때문에(신용카드 번호를 입력할 때 빈칸을 제거해야 한다는 식의), 일반 사용자가 그걸 생각해낼 수 있을지 장담 할 수 없습니다.
3. 보안은 사람과 관련된 문제다.
어떤 시스템의 보안 강도는 가장 약한 부분의 강도이다.
보안 관련 설정을 사용자에게 분담 시키지 말자. 어떤 기능의 설정 여부가 보안에 끼치는 영향을 잘 모른다.
117p - 컴퓨팅 분야의 거의 모든 문제와 마찬가지로 보안 또한 기술적 문제라기보다는 사람과 관련된 문제이다.
보안은 과정이지 제품이 아닙니다. 보안은 고리와 같아서 그 강도는 고리의 가장 약한 부분의 강도와 같다.
설계과정에서 인간의 본성을 인지하고 이해하고 고려하기 전까지는 사용자, 즉 인간이 항상 고리의 가장 약한 부분이고, 바로 이 부분이 고리가 끊기는 부분이 될 것이다.
138p - 대부분의 기능을 비활성화시켜 놓고 사용자가 필요한 기능만 활성화시켜 놓는 것이 모든 기능을 기본적으로 활성화시켜 놓고 사용자가 불필요한 것을 비활성화 시키도록 하는 것보다 훨씬 안전하다.
4. 인증 문제
각 인터넷 웹 싸이트마다 비밀번호 정책이 다르기 때문에 모든 싸이트의 비밀번호를 기억하기 힘들다.
그러면 매우 쉬운 비밀번호를 쓰거나, 적어 놓거나(사회 공학적 해킹에 취약) 하게 된다.
따라서 통합된 인증(현재 우리나라에서 은행에 상관없이 1개의 인증서를 등록해 사용 할 수 있는 것 처럼) 방법이 필요하다.
핵심 서비스가 아닌 부분을 아웃 소싱하듯 인증도 이런 방법이 필요하다.
171p - 개발자는 사용자의 삶을 쉽게 하기 위해 존재하기에 사용자가 아이다와 패스워드를 자유롭게 선택 할 수 있도록 해야 한다.
문자 선택의 제한을 두거나 강력한 패스워드를 요구하면 사용자는 패스워드를 적어 둘 것이고, 그러면 패스워드의 안정성은 포스트잇 수준으로 떨어진다.
5. 정확한 문제에 집중하자.
새로운 것을 만들 때 그것이 왜 유용하고, 왜 사용해야 하는지에 대해 고려하자.
기술만을 위한 기술을 사용하지 말고 풀어야하는 비즈니스 문제에 집중하라
238p - 괴짜는 문제 정의 기술, 즉 어떤 문제를 풀어나갈 것인지를 결정하는 방법이 부족하다.
240p - 괴짜는 사용 편의성이 모든 보안 시스템의 중요한 문제라는 것을 깨닫지 못한다.
유용한 싸이트
www.whysoftwaresucks.com : 이 책의 싸이트
www.webpagesthatsuck.com : 웹 디자인 전문가인 빈센트 플랜더스(Vincent Flanders)
참고 도서
Surely You're Joking, Mr. Feynman(파인만씨 농담도 잘 하시네1,2-사이너스 북스)
The Progress Rardox:How Life Gets Better While People Feel Worse - Random House, 2003
(진보의 역설 : 우리는 왜 더 잘살게 되었는데도 행복하지 않은가)
Cryptonomicon(크립토노미콘 1~4-책세상)
The Inmates Are Running the Asylum(정신병원에서 뛰쳐나온 디자인)