컬럼/인터뷰
로우 로젠펠드(Lou Rosenfeld)는 인포메이션 아키텍처 컨설턴트이자 『Information Architecture for the World Wide Web, 2nd Edition』의 공동저자이다. 스티브 크럭(Steve Krug)는 웹 사용성 전문가이며 『Don"t Make Me Think』의 저자이다. 이 둘은 각각 자신이 속한 분야에서 세미나를 이끄는 등 왕성한 활동을 하고 있으며 심포지움에서 연속 세션을 맡아 함께 진행하기도 했다.
이에 오라일리에서는 이 둘을 만나 그들이 함께 해나갈 조인트 세미나와 웹 사용성과 인포메이션 아키텍처에서 흔하게 빠지는 함정 및 오늘날 웹 산업 현황에 대해 의견을 나누었다.
스튜어트: 어떻게 해서 두 분이 함께 일을 벌이게 되셨나요?
크럭: 우리 두 사람이 같이 강연을 한다는게 꽤 괜찮아보이지 않나요? 실제로 사람들이 제 웹 사이트에 요청했던 바를 토대로 몇몇 도시에서의 워크샵을 계획하고 있긴 했습니다. 그러다가 로우가 제 일정에 대해 물어왔고 서로 이런 저런 이야기를 나누다가 ‘같이 강연을 해보는 것은 어떨까’라는 결론을 내리게 되었지요. 평소에도 저는 로우의 성실한 작업 스타일과 작업에 임하는 태도에 대해 칭찬을 아끼지 않았던 터라 우리 둘이 함께 강연을 한다는 것이 아주 근사하게 생각되더군요.
로젠펠드: 우리 작업 스타일이 서로 비슷하기 때문에 함께 일하는데 있어 전혀 거부감이 없었습니다. 둘 다 철저한 원리원칙 주의자도 아닌데다가 서로 재미있게 일하는걸 좋아하기 때문이죠. 사실 스티브는 아주 재밌는 사람입니다. 전 옆에서 그가 계속해서 재밌게 일할 수 있도록 격려해주기만 하면 되는 걸요.
스튜어트: 그래도 세미나는 두 분이 따로따로 하시는 걸로 알고 있습니다. 각자의 세미나에 같은 대상들을 끌어들일 생각이십니까?
로젠펠드: 지금까지는 등록자의 절반 정도가 두 세미나에 동시등록을 했습니다. 우리 둘이 다루는 주제가 상호보완적이어서 두 세미나에 등록했는지, 그냥 동시 등록의 경우 주어지는 할인 혜택 때문인지, 등록자들의 저의는 잘 모르겠지만 말입니다.
스튜어트: 사용성(usability)과 인포메이션 아키텍처! 제 생각엔 두 개가 똑같아 보이는데요.
크럭: 네, 정말 묘하게도 (사실 정확하게 알고 있는 사람은 거의 없지만) 그 두 개는 똑같은 것이랍니다. : ) (당황한 인터뷰어의 눈치를 살피며) 농담입니다. 농담! 분명 겹쳐지는 부분이 있긴 합니다만 절대 겹쳐질 수 없는 나름의 독자적인 영역이 있지요. 정보를 조직하는 구성 및 메커니즘을 실제로 설계하여 구축하는 것이 인포메이션 아키텍처라면 유저빌리티는 이와는 달리 이미 형성된 토대를 비판하여 허물어뜨리는 것에 가깝다고 할 수 있으니까요. 물론 이런 비판은 개선의 일환으로 시도되는 것이구요.
어떤 때는 내가 하고있는 일을 가장 잘 표현해주는 단어가 ‘쇼 전문가’라고 생각될 때가 있습니다. 흥행 전에 쇼를 관람하고 어떻게 하면 쇼가 더욱 흥미진진하게 보이는지를 연구하는 쇼 전문가 말입니다. 이런 사람들은 정말 보는 능력이 탁월해야 합니다. 웹 프로젝트를 해본적이 있다면 제 말이 어떤 뜻인지 더 확실하게 알 수 있을 겁니다. 내부의 정치적 분쟁에 개입되어 있지 않고, 외부인이자 최종 사용자의 입장에서, 상황을 판단하고 평가할 혜안을 갖고 있어야 하죠. 즉 만든 사람이 아니라 사용할 사람의 눈으로 판단할 지각을 가지고 있어야 한다는 것입니다.
물론 두 영역 간에 겹쳐지는 부분이 분명히 있어서 사용성 영역에서 너무 복잡하거나 전문적이지만 않다면 클라이언트에게 IA 문제에 대한 조언을 잘 해줄 수 있습니다. 물론 인포메이션 아키텍처 전문가들도 사용성에 대해 좋은 조언을 많이 해줄 수 있구요. 자신의 전문성이 언제 한계에 도달하는지 그 때를 아는 것이 중요하지요.
로젠펠드: 그렇습니다. 분명 훌륭한 인포메이션 아키텍처 전문가들은 사용성에 대해서도 잘 알고 있습니다. 하지만 프로젝트의 크기 및 복잡성에 따라 사용성 문제는 개입될 수도 그렇지 않을 수도 있다고 봅니다. 하지만 제 개인적으로는 사용성 전문가들이 적극적으로 개입되는 것을 추천하지만 말이죠.
스튜어트: 사용성에서 가장 흔하게 범하는 실수로는 무엇이 있습니까?
크럭: 정말 놀랍게도 홈페이지를 만든이가 누구인지, 무엇을 위한 사이트인지와 같이 아주 기본적인 정보를 아직까지도 제공하지 않는 홈페이지가 있습니다. 페이지 레이아웃(사이트 전체에 걸쳐 사용된 페이지 템플릿)의 시각적 계층이 잘못되어 컨텐츠를 말해주는 레이아웃도 전혀 엉뚱하게 되어버리는 경우도 있구요. 가장 고질적인 문제는 페이지에 너무 많은 것을 올려놓으려 한다는데 있습니다. 그 결과 눈에 확실히 띄는 것 없이 모두가 다 비슷하게 보이게 되지요.
스튜어트: 그렇다면 IA의 경우에는 어떻습니까?
로젠펠드: 사이트가 작으면 제자리에 있지 않은 것들을 다시 말쑥하게 수정하는 것이 쉬운편이죠. 실수가 쉽게 용인되고 쉽게 수정할 수도 있으니까요.
제가 우려하는 바는 보다 크고 복잡한 사이트들입니다. 이런 사이트에는 기업의 조직표와 부서별 정책이 반영됩니다. 대부분의 경우, 사용자들이 이와 같은 조직표를 암기하고 이를 지침으로 삼아 방대한 사이트의 컨텐츠를 보기 위해 서핑을 하지는 않을 것으로 생각됩니다. 실제로 큰 실수라고는 할 수 없겠지만, 기업이라는 현실에서는 가장 흔하게 일어나는 불행한 일임에는 틀림없죠.
아주 접근하기 어려운 문제이기도 한 것으로 웹 컨텐츠는 자연스럽게 사업 단위 사이의 경계선을 반영하는 "사일로우"에서 커집니다. 어떻게 이 기업급 웹 컨텐츠를 보다 더 사용자에게 친화적인 방식으로 재조직할 것인가? 그리고 어떻게 새로운 사용자 중심의 정보 골격구조를 지원하도록 기업 그 자체를 변화시킬 것인가? 이런 것들이 이번 세미나에서 접근하는 이슈들입니다.
스튜어트: 언제나 간단할수록 더 좋습니까?
크럭: 아닙니다. 물론 "언제나"는 아니지요. 어떤 상황에서는 복잡하고, 심지어 과도하게 붐비는 것이 더 좋을 때도 있습니다. 그러나 명료성의 경우에는 언제나 더 간단할수록 좋습니다. 사람들은 종종 간결함과 명료성을 혼동해서, 복잡하더라도 명료한 것이 있을 수 있다는 것을 잊어버립니다. 여러분이 듣게 되는 말을 정리하면 다음과 같습니다. "더 간단하게 만들면, 파워 유저들은 화를 낼 것이다." 그러나 나의 경험으로 보아 파워 유저들은 절대로 명료성 때문에 화를 내지는 않습니다. 사실 그들은 누구보다도 명료성을 높이 평가합니다. 그들이 싫어하는 것은 일을 파악하느라 시간을 낭비하는 것입니다. 그 이유가 그 사이트를 구축한 사람들이 명료하게 만드는 수고를 하지 않았기 때문에 말입니다.
스튜어트: 디자이너들이 아주 복잡하거나 아주 많은 정보를 다루는 사이트를 다룰 때 반드시 생각해야 할 것이 있다면 어떤 것들이 있지요?
로젠펠드: 많은 사용자들에게 혜택을 주는(페이지 안내에서부터 최적 탐색 결과에 이르기까지) "가벼운" 아키텍처 접근법이 많이 있습니다. 게다가 개발하고 구현하는데 많은 비용이 들지 않습니다. 이런 것들에 재빨리 참여하면 시간을 벌 수 있을 뿐만 아니라 시각적 편의를 증진하면서 더욱 위협적이고 장기적인 도전에 어떻게 대처해야 할지 결정할 수 있습니다.
또 다른 사항으로는 윤리적 속임수를 사용하는 것입니다. 주의깊게 생각해서 계획하면, 보통 자기가 속한 부서의 웹 컨텐츠, 사용자, 그리고 정략에 초점을 맞추고 있는 사람들을 속여서 전체 조직의 이익에 초점을 두도록 만들 수 있습니다. 예를 들어 나는 가끔 청중 분류 과정을 슬쩍 돌려서 조직표에 전혀 관련이 없는 당면과제 샘플(subject samples)들을 마련하는데 초점을 맞출 수도 있다고 생각합니다. 그래도 정책 결정자들은 여전히 모를 것입니다(none the wiser).
스튜어트: 사용성이나 인포메이션 아키텍처에 순서를 매길만한 규칙이 있습니까?
크럭: 글쎄요, 저는 "생각하게 만들지마(Don"t make me think)"라는 메시지를 유달리 좋아합니다. 그리고 다음과 같이 최우선으로 삼을 좋은 원칙을 발견했습니다. 일에 몰두하라! 그리고 그것을 사람들에게 계속 보여주라! 스스로 명백해져서 이해가 될 때까지 말이다! 사용자들의 머리에 떠 다니는 의문표를 모조리 없애 버리자!
그렇지만 대부분의 경우, 저는 규칙보다는 태도와 전략을 가르치려고 합니다. 잘 작동하는 사이트를 디자인하는 작업은 언제나 아슬아슬한 작업입니다. 공간의 활용을 최우선으로 해서 청중과 출간인 모두 그들의 목표를 완수하도록 돕습니다. 조감을 적절하게 조절하고 포맷해서 충분하게 유용한/적절한 주목을 받도록 해 줍니다. 항상 여러분은 수 많은 변수들에 대해서 최적화하려고 시도합니다(보통 너무 많습니다). 동시에, 저것을 너무 많이 보여주지 않고 이것을 충분히 보여줍니다. 그리고 보편적 규칙이 아주 많이 존재하지는 않는데, 한 디자인 맥락에서 잘 작동하는 해결책이라도 다른 디자인 상황에서는 작동하지 않기 때문입니다.
로젠펠드: 규칙은 인포메이션 아키텍처(IA)에서도 잘 작동하지 않습니다. 사실, 까다로운 IA 질문에 대한 "정답"은 "~에 따라서"입니다. 머리에 떠 오르는 유일한 "규칙"은 파레토 원리(Pareto Principle)라는 것인데, 이른바 80/20 규칙이라고 알려져 있습니다. 이 규칙은 실제로는 전혀 규칙이 아닙니다.
파레토 규칙이 IA에서 작동하는 방식은 기본적으로 상당히 많은 사용자들이 가능한 모든 아키텍처 접근법에서 몇 가지 선택으로부터 혜택을 입을 것이라는 것입니다. 그래서 여러분과 그 사용자들에게 돈을 지불한 대가(bang for your buck)를 최대로 돌려주는 가장 좋은 방식을 몇 가지 선택합니다. 파레토 규칙에는 다른 변형이 많습니다. 예를 들어, 가장 흔한 탐색 몇 가지는 수 없이 많은 탐색으로 구성됩니다(그리고 수작업으로 개발된 "최적 일치(best bet)" 결과로 접근할 수 있습니다). 믿지 못 하시겠다면 여러분의 탐색 기록을 점검해 보세요.
스튜어트: 브라우저의 역사에서 오늘날 웹 디자이너들은 얼마나 거슬러 올라가 신경써야 할까요? 테스트하기를 추천하는 가장 오래된 브라우저는 무엇인가요?
크럭: 정말 어려운 질문이군요. 뭐라고 말해도 곤란하겠네요. 개인적으로 전자우편 클라이언트를 좋아하기 때문에, 저는 거의 대부분 구식 Netscape 4.77 브라우저를 여전히 사용하고 있는데, 어떤 사이트는 열리지 않습니다(페이지 상단에는 로고가 보이지만, 나머지는 비어 있지요). 그러나 내가 구형 브라우저를 사용하기로 결정했기 때문에 그것은 제 개인적인 문제라는 것이죠. 그래서 그런 일이 일어나더라도 그 사이트의 개발자를 원망하지는 않습니다.
그러나 어떤 사람들은 예전 브라우저의 사용 고집합니다(회사 정책, 정말 오래된 하드웨어, 혹은 새로운 브라우저를 내려받을 수 없을 정도로 느린 연결 때문에), 혹 어떤 사람들은 오프-브랜드 브라우저를 정말 좋아합니다. 점차 시대에 뒤떨어지고 있다는 사실(graceful degradation)을 완전히 인지하고 있으면(구형 브라우저에서도 완전하지는 않지만, 쓸모 있는 경험을 제공할 수 있다는 확신을 가지고), 아마도 괜찮을 것입니다. 그러나 또다시, 그것은 종종 교환관계에 봉착합니다. 모든 브라우저를 지원하는 데 얼마나 많은 노력을 투입할 수 있는가?
스튜어트: 사용자 테스트가 중요하다는 것은 누구라도 압니다. 이를 성공적으로 완수하는 열쇠는 무엇입니까?
크럭: 가장 중요한 일은 최대한 간단하게 사용자 테스트를 유지하여 실제로 수행할 수 있도록 해 주는 것입니다. 디자인 과정에서 일찍 사용자 테스트를 시작해서, 일정 간격으로 사용자 테스트를 하고, 테스트 중에 발견된 문제들을 고치는 테스트는 절대 간과할 수 없을 귀중한 단계입니다. 그러나 여전히 많은 사람들은 "유효한" 샘플을 얻기 위해 다섯 혹은 여덟 또는 열 두 명의 사람만 테스트하면 된다고 생각합니다. 그것은 완전히 잘못된 태도입니다. 그렇게 되면 결과적으로 테스트를 단 한번으로 끝내게 되고, 디자인이 거의 끝나갈 무렵에야 테스트를 하게 됩니다. 이렇게 테스트를 하기보다는 여러 사람을 한 번(두 번이나 세 번도 좋음)에 끌어 들인 후, 자유로운 분위기를 유지하면서 매 3주나 4주 마다 사용자 테스트를 해야 하죠.
스튜어트: 로우(Lou)씨, 왜 기업급 설정에 초점을 두고 있습니까? 뭐 "스타 트랙(Star Trek)" 집착 같은 것일까요?
로젠펠드: TV에서 "The Enterprise"라는 이름은 잘못 붙인 겁니다. 왜냐하면, 거대하고 복잡한 개체가 효율적으로 실행되고 있기 때문이지요. (물론 커크(Kirk)는 제외하고) 자아를 문 앞에 버려두고 온 고도의 능력을 가진 정책 결정자들로 이루어진 소규모 간부 그룹에 의해서 말입니다. 그들이 원하는 모든 정보는 거대한 인공 지능 존재에 의해서 즉시 열람되고, 조합되고, 분석되고, 다듬어져 튀어 나옵니다. 이 존재는 분명히 윈도우즈보다는 더 안정적인 어떤 것 위에서 실행 중인 것 같습니다. 현실세계의 기업은 거대하고 복잡하다는 점에서만 비슷합니다. 현실의 기업은 효율적이지 않아서, 자주 웹 컨텐츠를 다시 또 만들어내고 또다시 소프트웨어를 중복 구입합니다. 현실세계의 기업은 어쩔 수 없이 정치적이라서, 막강한 권력을 쥐고 있는 부사장이 디자인을 결정하는 경우가 자주 있습니다. 자율적인 비즈니스 단위 전쟁의 틈바구니에서 현실세계의 기업은 중앙 집권(예, 집행부) 때문에 조율되지 않습니다.
이렇게 이리 저리 하다보니, 사용자들은 대상에서 제외됩니다. 그래서 사용자의 필요를 만족시키기 위해 디자인되기 보다, 기업급 정보 골격구조는 조직적으로 자라나서 조직표의 정치적인 경계선을 반영합니다. 왜 내가 이런 이슈에 집착하는가? 음, 개인적으로, 나는 소형의 단순한 사이트에 대해서 골격구조를 디자인해 주고, 수표를 집어 들고 돌아와서, 편한 마음으로 자는 것을 더 좋아합니다. 그러나 지난 삼년간 대화를 나누어 본 잠재고객(prospect)과 단골고객(client)은 거의 누구나 조직의 기업급 정보 골격구조를 개선하는 도전과제에 접근하지 못하는 것을 불평했습니다. 그래서 집착은 그들이 하는 거지요. 세미나는 그저 도와주려는 나의 노력일 뿐입니다(그렇다고 세미나 중에 밖에 나가지는 마시기 바랍니다).
스튜어트: 스티브(Steve)씨, 왜 당신은 로우(Lou)씨처럼 이런 "기업적" 맥락에 집착하지 않습니까? "기업급 사용성" 역시 큰 문제가 아닌가요?
크럭: 사용성 문제는 IA 문제보다 정치적인 부담이 약간 더 적은 것으로 드러났습니다. IA는 조직에서 서로 다른 부분들이 웹 사이트에 의해 어떻게 표현되어야 할 지에 대해 더 직접적인 충격을 줍니다("방송 시간"의 할당). 그리고 IA 처리과정은 기업 자체가 조직되어 있는 방식에서 기존의 문제들과 불합리를 훑는 경향이 있습니다. 특히 내부 조직이 외부의 청중에게 아무런 의미도 없는 영역에서 말입니다.
스튜어트: 사용성과 IA에서 다자이너들에게 가장 큰 도전과제는 무엇이라고 보십니까?
크럭: 충분히 잠을 자는 것입니다. 사용성에서 가장 큰 문제는 종종 수정할 시간은 있으나, 수정에 무엇이 필요한지 모르는 것입니다. 사실상 대부분의 웹 디자이너들(그리고 개발자들)은 오히려 시간이 모자랍니다. 다른 큰 도전과제는 일에서 어느 정도 거리를 두는 것입니다. 한 프로젝트에 몇 주(몇 달은 물론이고)동안 매달리게 되면, 다시 되돌아와 사용자의 관점에서 그 프로젝트를 바라보는 것이 거의 불가능합니다. 그 때문에 프로젝트에 참여한 사람들이 자신들이 만든 구축물을 다른 사람들에게 사용해보도록 하고 그들이 사용하는 것을 꾸준히 지켜 보는 일(이른바 "사용성 테스트"가)이 아주 중요한 도전과제가 되지요.
로젠펠드: 디자인을 하는 사람들에게 있어서 가장 큰 도전과제는 자신의 작업에 드는 비용을 정당화하는 문제라고 생각합니다. 어느 경우에나 항상 문제가 뒤따르게 되는데 그것이 바로 투자 수익(ROI, return on investment)입니다.
IA에 대해서 특별히 확실한 투자수익(ROI) 분석 사례는 보지 못했지만, 비용을 정당화하기 어려운 기타 애매한 영역의 가치를 이해하듯이 점점 더 많은 사람들이 IA의 내재적인 가치를 똑같은 방식으로 이해하는 것 같습니다. 예를 들면 시장판매(marketing) 예산이 그렇습니다. 그래서 나는 낙관합니다.
스튜어트: 워크샵에 참석한 사람들이 워크샵이 끝난 후에는 어떤 것들을 가지고 나가길 바라시나요?
크럭: 제 워크샵에 다음과 같이 부제를 붙이고 있습니다. "8시간 안에 사용성 전문가처럼 생각하는 법을 배우자!"라고 말입니다. 그리고 이 선전문구를 자신 만만하게 믿습니다. 나의 목표는 사람들이 더 나은 사용성 감각을 가지고, 사이트를 구축하면서 제기되는 질문에 대한 해답을 알도록 하는데 있습니다. 스스로 사용성 테스트를 하는 법, 그리고 발견된 문제의 해결에 접근하는 법을 알려 주는 것입니다
로젠펠드: 저도 정말 그러기를 바랍니다.
심각한 것은 내가 대화를 나누어 본 사람들은 생각보다 훨씬 더 절망감을 느낀다는 겁니다. 그들의 절망은 종종 반복적인 난관주의나 선임관리자의 무지에 대한 반응입니다. 선임 관리자들은 기업급 정보 골격구조를 다시 디자인하는 도전은 별 문제가 되지 않는 아주 쉬운 일이라고 생각합니다.
제 세미나에 참석한 사람들이 즉시 혹은 빠른 시일 내에 구현할 수 있는 실용적인 디자인 개념을 가지고 떠났으면 합니다. 장기적으로 작업할 현실적인 계획 그리고 목표와 균형을 이루어서 말입니다. 그들이 어느 "교과서"적 연구 방법이 기업적 맥락에서 작동하고 작동하지 않는지 더 좋은 감각을 가지기를 바랍니다. 그리고 한가지 작업틀을 가지고 돌아가 조직에서 기업적 팀을 이루어 IA 문제들을 해결하는데 지침이 되기를 바랍니다.
스튜어트: 바깥 경기를 생각해볼 때 어떻습니까? 사용성과 IA에 돈을 쓸 능력이 될 사람들이 있을까요?
로젠펠드: 불경기이기는 하지만, 적어도 미 연방 정부는 IA에 어느 정도는 지출을 하고 있습니다. 왜 그런지는 묻지 마세요. 거대 기업들초차도 IA 문제들에 접근하는데 필요한 최소한의 자금을 모으고 있는 듯 합니다. 그냥 그들은 소프트웨어 도구들에다 돈을 지출하려고 하지 않을 따름입니다. 전문가를 초빙함으로써 그런 투자가치를 높이려고 더욱 더 노력하고 있습니다. 사실, 많은 기업들이 현재 전업제 IA 전문가들을 간부로 채택하고 있다는 사실에 놀랐습니다. 이런 것들을 볼 때, 낙관적이란 생각이 들지 않습니까?
크럭: 상당히 많은 사람들부터 들은 이야기에 의하면 경기가 여전히 아주 힘들다고 합니다. 이제서야 생각보다 많은 회사들이 사용성에 노력을 기울여야 한다는 사실을 깨닫고 있지만, 프로젝트 예산의 표준 라인에 들기에는 여전히 거리가 멀다고 생각합니다. 들은 바로는 많은 회사들이 관심을 표명하고 사용성에 관하여 문의하지만, 실제로 거기에 돈을 쓰는 결정을 내리는데 이르지는 못하는 것 같습니다.
사용성에 돈을 쓰는 회사들은 웹에 방대한 투자를 하고 있는 거대 회사들이고, 그 보다 작은 회사에서는 관리자들이 이전에 사용성에 경험이 있고, 그냥 비용을 지출하는 대신, 디자인 과정을 실제로 거대회사들 보다 더 쉽고 빠르게 만들 수 있다는 것을 알고 있는 경우에 사용성에 비용을 지출합니다.
이에 오라일리에서는 이 둘을 만나 그들이 함께 해나갈 조인트 세미나와 웹 사용성과 인포메이션 아키텍처에서 흔하게 빠지는 함정 및 오늘날 웹 산업 현황에 대해 의견을 나누었다.
스튜어트: 어떻게 해서 두 분이 함께 일을 벌이게 되셨나요?
크럭: 우리 두 사람이 같이 강연을 한다는게 꽤 괜찮아보이지 않나요? 실제로 사람들이 제 웹 사이트에 요청했던 바를 토대로 몇몇 도시에서의 워크샵을 계획하고 있긴 했습니다. 그러다가 로우가 제 일정에 대해 물어왔고 서로 이런 저런 이야기를 나누다가 ‘같이 강연을 해보는 것은 어떨까’라는 결론을 내리게 되었지요. 평소에도 저는 로우의 성실한 작업 스타일과 작업에 임하는 태도에 대해 칭찬을 아끼지 않았던 터라 우리 둘이 함께 강연을 한다는 것이 아주 근사하게 생각되더군요.
로젠펠드: 우리 작업 스타일이 서로 비슷하기 때문에 함께 일하는데 있어 전혀 거부감이 없었습니다. 둘 다 철저한 원리원칙 주의자도 아닌데다가 서로 재미있게 일하는걸 좋아하기 때문이죠. 사실 스티브는 아주 재밌는 사람입니다. 전 옆에서 그가 계속해서 재밌게 일할 수 있도록 격려해주기만 하면 되는 걸요.
스튜어트: 그래도 세미나는 두 분이 따로따로 하시는 걸로 알고 있습니다. 각자의 세미나에 같은 대상들을 끌어들일 생각이십니까?
로젠펠드: 지금까지는 등록자의 절반 정도가 두 세미나에 동시등록을 했습니다. 우리 둘이 다루는 주제가 상호보완적이어서 두 세미나에 등록했는지, 그냥 동시 등록의 경우 주어지는 할인 혜택 때문인지, 등록자들의 저의는 잘 모르겠지만 말입니다.
스튜어트: 사용성(usability)과 인포메이션 아키텍처! 제 생각엔 두 개가 똑같아 보이는데요.
크럭: 네, 정말 묘하게도 (사실 정확하게 알고 있는 사람은 거의 없지만) 그 두 개는 똑같은 것이랍니다. : ) (당황한 인터뷰어의 눈치를 살피며) 농담입니다. 농담! 분명 겹쳐지는 부분이 있긴 합니다만 절대 겹쳐질 수 없는 나름의 독자적인 영역이 있지요. 정보를 조직하는 구성 및 메커니즘을 실제로 설계하여 구축하는 것이 인포메이션 아키텍처라면 유저빌리티는 이와는 달리 이미 형성된 토대를 비판하여 허물어뜨리는 것에 가깝다고 할 수 있으니까요. 물론 이런 비판은 개선의 일환으로 시도되는 것이구요.
어떤 때는 내가 하고있는 일을 가장 잘 표현해주는 단어가 ‘쇼 전문가’라고 생각될 때가 있습니다. 흥행 전에 쇼를 관람하고 어떻게 하면 쇼가 더욱 흥미진진하게 보이는지를 연구하는 쇼 전문가 말입니다. 이런 사람들은 정말 보는 능력이 탁월해야 합니다. 웹 프로젝트를 해본적이 있다면 제 말이 어떤 뜻인지 더 확실하게 알 수 있을 겁니다. 내부의 정치적 분쟁에 개입되어 있지 않고, 외부인이자 최종 사용자의 입장에서, 상황을 판단하고 평가할 혜안을 갖고 있어야 하죠. 즉 만든 사람이 아니라 사용할 사람의 눈으로 판단할 지각을 가지고 있어야 한다는 것입니다.
물론 두 영역 간에 겹쳐지는 부분이 분명히 있어서 사용성 영역에서 너무 복잡하거나 전문적이지만 않다면 클라이언트에게 IA 문제에 대한 조언을 잘 해줄 수 있습니다. 물론 인포메이션 아키텍처 전문가들도 사용성에 대해 좋은 조언을 많이 해줄 수 있구요. 자신의 전문성이 언제 한계에 도달하는지 그 때를 아는 것이 중요하지요.
로젠펠드: 그렇습니다. 분명 훌륭한 인포메이션 아키텍처 전문가들은 사용성에 대해서도 잘 알고 있습니다. 하지만 프로젝트의 크기 및 복잡성에 따라 사용성 문제는 개입될 수도 그렇지 않을 수도 있다고 봅니다. 하지만 제 개인적으로는 사용성 전문가들이 적극적으로 개입되는 것을 추천하지만 말이죠.
스튜어트: 사용성에서 가장 흔하게 범하는 실수로는 무엇이 있습니까?
크럭: 정말 놀랍게도 홈페이지를 만든이가 누구인지, 무엇을 위한 사이트인지와 같이 아주 기본적인 정보를 아직까지도 제공하지 않는 홈페이지가 있습니다. 페이지 레이아웃(사이트 전체에 걸쳐 사용된 페이지 템플릿)의 시각적 계층이 잘못되어 컨텐츠를 말해주는 레이아웃도 전혀 엉뚱하게 되어버리는 경우도 있구요. 가장 고질적인 문제는 페이지에 너무 많은 것을 올려놓으려 한다는데 있습니다. 그 결과 눈에 확실히 띄는 것 없이 모두가 다 비슷하게 보이게 되지요.
스튜어트: 그렇다면 IA의 경우에는 어떻습니까?
로젠펠드: 사이트가 작으면 제자리에 있지 않은 것들을 다시 말쑥하게 수정하는 것이 쉬운편이죠. 실수가 쉽게 용인되고 쉽게 수정할 수도 있으니까요.
제가 우려하는 바는 보다 크고 복잡한 사이트들입니다. 이런 사이트에는 기업의 조직표와 부서별 정책이 반영됩니다. 대부분의 경우, 사용자들이 이와 같은 조직표를 암기하고 이를 지침으로 삼아 방대한 사이트의 컨텐츠를 보기 위해 서핑을 하지는 않을 것으로 생각됩니다. 실제로 큰 실수라고는 할 수 없겠지만, 기업이라는 현실에서는 가장 흔하게 일어나는 불행한 일임에는 틀림없죠.
아주 접근하기 어려운 문제이기도 한 것으로 웹 컨텐츠는 자연스럽게 사업 단위 사이의 경계선을 반영하는 "사일로우"에서 커집니다. 어떻게 이 기업급 웹 컨텐츠를 보다 더 사용자에게 친화적인 방식으로 재조직할 것인가? 그리고 어떻게 새로운 사용자 중심의 정보 골격구조를 지원하도록 기업 그 자체를 변화시킬 것인가? 이런 것들이 이번 세미나에서 접근하는 이슈들입니다.
스튜어트: 언제나 간단할수록 더 좋습니까?
크럭: 아닙니다. 물론 "언제나"는 아니지요. 어떤 상황에서는 복잡하고, 심지어 과도하게 붐비는 것이 더 좋을 때도 있습니다. 그러나 명료성의 경우에는 언제나 더 간단할수록 좋습니다. 사람들은 종종 간결함과 명료성을 혼동해서, 복잡하더라도 명료한 것이 있을 수 있다는 것을 잊어버립니다. 여러분이 듣게 되는 말을 정리하면 다음과 같습니다. "더 간단하게 만들면, 파워 유저들은 화를 낼 것이다." 그러나 나의 경험으로 보아 파워 유저들은 절대로 명료성 때문에 화를 내지는 않습니다. 사실 그들은 누구보다도 명료성을 높이 평가합니다. 그들이 싫어하는 것은 일을 파악하느라 시간을 낭비하는 것입니다. 그 이유가 그 사이트를 구축한 사람들이 명료하게 만드는 수고를 하지 않았기 때문에 말입니다.
스튜어트: 디자이너들이 아주 복잡하거나 아주 많은 정보를 다루는 사이트를 다룰 때 반드시 생각해야 할 것이 있다면 어떤 것들이 있지요?
로젠펠드: 많은 사용자들에게 혜택을 주는(페이지 안내에서부터 최적 탐색 결과에 이르기까지) "가벼운" 아키텍처 접근법이 많이 있습니다. 게다가 개발하고 구현하는데 많은 비용이 들지 않습니다. 이런 것들에 재빨리 참여하면 시간을 벌 수 있을 뿐만 아니라 시각적 편의를 증진하면서 더욱 위협적이고 장기적인 도전에 어떻게 대처해야 할지 결정할 수 있습니다.
또 다른 사항으로는 윤리적 속임수를 사용하는 것입니다. 주의깊게 생각해서 계획하면, 보통 자기가 속한 부서의 웹 컨텐츠, 사용자, 그리고 정략에 초점을 맞추고 있는 사람들을 속여서 전체 조직의 이익에 초점을 두도록 만들 수 있습니다. 예를 들어 나는 가끔 청중 분류 과정을 슬쩍 돌려서 조직표에 전혀 관련이 없는 당면과제 샘플(subject samples)들을 마련하는데 초점을 맞출 수도 있다고 생각합니다. 그래도 정책 결정자들은 여전히 모를 것입니다(none the wiser).
|
참고 도서 효율적인 웹사이트 구축을 위한 인포메이션 아키텍처 |
스튜어트: 사용성이나 인포메이션 아키텍처에 순서를 매길만한 규칙이 있습니까?
크럭: 글쎄요, 저는 "생각하게 만들지마(Don"t make me think)"라는 메시지를 유달리 좋아합니다. 그리고 다음과 같이 최우선으로 삼을 좋은 원칙을 발견했습니다. 일에 몰두하라! 그리고 그것을 사람들에게 계속 보여주라! 스스로 명백해져서 이해가 될 때까지 말이다! 사용자들의 머리에 떠 다니는 의문표를 모조리 없애 버리자!
그렇지만 대부분의 경우, 저는 규칙보다는 태도와 전략을 가르치려고 합니다. 잘 작동하는 사이트를 디자인하는 작업은 언제나 아슬아슬한 작업입니다. 공간의 활용을 최우선으로 해서 청중과 출간인 모두 그들의 목표를 완수하도록 돕습니다. 조감을 적절하게 조절하고 포맷해서 충분하게 유용한/적절한 주목을 받도록 해 줍니다. 항상 여러분은 수 많은 변수들에 대해서 최적화하려고 시도합니다(보통 너무 많습니다). 동시에, 저것을 너무 많이 보여주지 않고 이것을 충분히 보여줍니다. 그리고 보편적 규칙이 아주 많이 존재하지는 않는데, 한 디자인 맥락에서 잘 작동하는 해결책이라도 다른 디자인 상황에서는 작동하지 않기 때문입니다.
로젠펠드: 규칙은 인포메이션 아키텍처(IA)에서도 잘 작동하지 않습니다. 사실, 까다로운 IA 질문에 대한 "정답"은 "~에 따라서"입니다. 머리에 떠 오르는 유일한 "규칙"은 파레토 원리(Pareto Principle)라는 것인데, 이른바 80/20 규칙이라고 알려져 있습니다. 이 규칙은 실제로는 전혀 규칙이 아닙니다.
파레토 규칙이 IA에서 작동하는 방식은 기본적으로 상당히 많은 사용자들이 가능한 모든 아키텍처 접근법에서 몇 가지 선택으로부터 혜택을 입을 것이라는 것입니다. 그래서 여러분과 그 사용자들에게 돈을 지불한 대가(bang for your buck)를 최대로 돌려주는 가장 좋은 방식을 몇 가지 선택합니다. 파레토 규칙에는 다른 변형이 많습니다. 예를 들어, 가장 흔한 탐색 몇 가지는 수 없이 많은 탐색으로 구성됩니다(그리고 수작업으로 개발된 "최적 일치(best bet)" 결과로 접근할 수 있습니다). 믿지 못 하시겠다면 여러분의 탐색 기록을 점검해 보세요.
스튜어트: 브라우저의 역사에서 오늘날 웹 디자이너들은 얼마나 거슬러 올라가 신경써야 할까요? 테스트하기를 추천하는 가장 오래된 브라우저는 무엇인가요?
크럭: 정말 어려운 질문이군요. 뭐라고 말해도 곤란하겠네요. 개인적으로 전자우편 클라이언트를 좋아하기 때문에, 저는 거의 대부분 구식 Netscape 4.77 브라우저를 여전히 사용하고 있는데, 어떤 사이트는 열리지 않습니다(페이지 상단에는 로고가 보이지만, 나머지는 비어 있지요). 그러나 내가 구형 브라우저를 사용하기로 결정했기 때문에 그것은 제 개인적인 문제라는 것이죠. 그래서 그런 일이 일어나더라도 그 사이트의 개발자를 원망하지는 않습니다.
그러나 어떤 사람들은 예전 브라우저의 사용 고집합니다(회사 정책, 정말 오래된 하드웨어, 혹은 새로운 브라우저를 내려받을 수 없을 정도로 느린 연결 때문에), 혹 어떤 사람들은 오프-브랜드 브라우저를 정말 좋아합니다. 점차 시대에 뒤떨어지고 있다는 사실(graceful degradation)을 완전히 인지하고 있으면(구형 브라우저에서도 완전하지는 않지만, 쓸모 있는 경험을 제공할 수 있다는 확신을 가지고), 아마도 괜찮을 것입니다. 그러나 또다시, 그것은 종종 교환관계에 봉착합니다. 모든 브라우저를 지원하는 데 얼마나 많은 노력을 투입할 수 있는가?
스튜어트: 사용자 테스트가 중요하다는 것은 누구라도 압니다. 이를 성공적으로 완수하는 열쇠는 무엇입니까?
크럭: 가장 중요한 일은 최대한 간단하게 사용자 테스트를 유지하여 실제로 수행할 수 있도록 해 주는 것입니다. 디자인 과정에서 일찍 사용자 테스트를 시작해서, 일정 간격으로 사용자 테스트를 하고, 테스트 중에 발견된 문제들을 고치는 테스트는 절대 간과할 수 없을 귀중한 단계입니다. 그러나 여전히 많은 사람들은 "유효한" 샘플을 얻기 위해 다섯 혹은 여덟 또는 열 두 명의 사람만 테스트하면 된다고 생각합니다. 그것은 완전히 잘못된 태도입니다. 그렇게 되면 결과적으로 테스트를 단 한번으로 끝내게 되고, 디자인이 거의 끝나갈 무렵에야 테스트를 하게 됩니다. 이렇게 테스트를 하기보다는 여러 사람을 한 번(두 번이나 세 번도 좋음)에 끌어 들인 후, 자유로운 분위기를 유지하면서 매 3주나 4주 마다 사용자 테스트를 해야 하죠.
스튜어트: 로우(Lou)씨, 왜 기업급 설정에 초점을 두고 있습니까? 뭐 "스타 트랙(Star Trek)" 집착 같은 것일까요?
로젠펠드: TV에서 "The Enterprise"라는 이름은 잘못 붙인 겁니다. 왜냐하면, 거대하고 복잡한 개체가 효율적으로 실행되고 있기 때문이지요. (물론 커크(Kirk)는 제외하고) 자아를 문 앞에 버려두고 온 고도의 능력을 가진 정책 결정자들로 이루어진 소규모 간부 그룹에 의해서 말입니다. 그들이 원하는 모든 정보는 거대한 인공 지능 존재에 의해서 즉시 열람되고, 조합되고, 분석되고, 다듬어져 튀어 나옵니다. 이 존재는 분명히 윈도우즈보다는 더 안정적인 어떤 것 위에서 실행 중인 것 같습니다. 현실세계의 기업은 거대하고 복잡하다는 점에서만 비슷합니다. 현실의 기업은 효율적이지 않아서, 자주 웹 컨텐츠를 다시 또 만들어내고 또다시 소프트웨어를 중복 구입합니다. 현실세계의 기업은 어쩔 수 없이 정치적이라서, 막강한 권력을 쥐고 있는 부사장이 디자인을 결정하는 경우가 자주 있습니다. 자율적인 비즈니스 단위 전쟁의 틈바구니에서 현실세계의 기업은 중앙 집권(예, 집행부) 때문에 조율되지 않습니다.
이렇게 이리 저리 하다보니, 사용자들은 대상에서 제외됩니다. 그래서 사용자의 필요를 만족시키기 위해 디자인되기 보다, 기업급 정보 골격구조는 조직적으로 자라나서 조직표의 정치적인 경계선을 반영합니다. 왜 내가 이런 이슈에 집착하는가? 음, 개인적으로, 나는 소형의 단순한 사이트에 대해서 골격구조를 디자인해 주고, 수표를 집어 들고 돌아와서, 편한 마음으로 자는 것을 더 좋아합니다. 그러나 지난 삼년간 대화를 나누어 본 잠재고객(prospect)과 단골고객(client)은 거의 누구나 조직의 기업급 정보 골격구조를 개선하는 도전과제에 접근하지 못하는 것을 불평했습니다. 그래서 집착은 그들이 하는 거지요. 세미나는 그저 도와주려는 나의 노력일 뿐입니다(그렇다고 세미나 중에 밖에 나가지는 마시기 바랍니다).
스튜어트: 스티브(Steve)씨, 왜 당신은 로우(Lou)씨처럼 이런 "기업적" 맥락에 집착하지 않습니까? "기업급 사용성" 역시 큰 문제가 아닌가요?
크럭: 사용성 문제는 IA 문제보다 정치적인 부담이 약간 더 적은 것으로 드러났습니다. IA는 조직에서 서로 다른 부분들이 웹 사이트에 의해 어떻게 표현되어야 할 지에 대해 더 직접적인 충격을 줍니다("방송 시간"의 할당). 그리고 IA 처리과정은 기업 자체가 조직되어 있는 방식에서 기존의 문제들과 불합리를 훑는 경향이 있습니다. 특히 내부 조직이 외부의 청중에게 아무런 의미도 없는 영역에서 말입니다.
스튜어트: 사용성과 IA에서 다자이너들에게 가장 큰 도전과제는 무엇이라고 보십니까?
크럭: 충분히 잠을 자는 것입니다. 사용성에서 가장 큰 문제는 종종 수정할 시간은 있으나, 수정에 무엇이 필요한지 모르는 것입니다. 사실상 대부분의 웹 디자이너들(그리고 개발자들)은 오히려 시간이 모자랍니다. 다른 큰 도전과제는 일에서 어느 정도 거리를 두는 것입니다. 한 프로젝트에 몇 주(몇 달은 물론이고)동안 매달리게 되면, 다시 되돌아와 사용자의 관점에서 그 프로젝트를 바라보는 것이 거의 불가능합니다. 그 때문에 프로젝트에 참여한 사람들이 자신들이 만든 구축물을 다른 사람들에게 사용해보도록 하고 그들이 사용하는 것을 꾸준히 지켜 보는 일(이른바 "사용성 테스트"가)이 아주 중요한 도전과제가 되지요.
로젠펠드: 디자인을 하는 사람들에게 있어서 가장 큰 도전과제는 자신의 작업에 드는 비용을 정당화하는 문제라고 생각합니다. 어느 경우에나 항상 문제가 뒤따르게 되는데 그것이 바로 투자 수익(ROI, return on investment)입니다.
IA에 대해서 특별히 확실한 투자수익(ROI) 분석 사례는 보지 못했지만, 비용을 정당화하기 어려운 기타 애매한 영역의 가치를 이해하듯이 점점 더 많은 사람들이 IA의 내재적인 가치를 똑같은 방식으로 이해하는 것 같습니다. 예를 들면 시장판매(marketing) 예산이 그렇습니다. 그래서 나는 낙관합니다.
스튜어트: 워크샵에 참석한 사람들이 워크샵이 끝난 후에는 어떤 것들을 가지고 나가길 바라시나요?
크럭: 제 워크샵에 다음과 같이 부제를 붙이고 있습니다. "8시간 안에 사용성 전문가처럼 생각하는 법을 배우자!"라고 말입니다. 그리고 이 선전문구를 자신 만만하게 믿습니다. 나의 목표는 사람들이 더 나은 사용성 감각을 가지고, 사이트를 구축하면서 제기되는 질문에 대한 해답을 알도록 하는데 있습니다. 스스로 사용성 테스트를 하는 법, 그리고 발견된 문제의 해결에 접근하는 법을 알려 주는 것입니다
로젠펠드: 저도 정말 그러기를 바랍니다.
심각한 것은 내가 대화를 나누어 본 사람들은 생각보다 훨씬 더 절망감을 느낀다는 겁니다. 그들의 절망은 종종 반복적인 난관주의나 선임관리자의 무지에 대한 반응입니다. 선임 관리자들은 기업급 정보 골격구조를 다시 디자인하는 도전은 별 문제가 되지 않는 아주 쉬운 일이라고 생각합니다.
제 세미나에 참석한 사람들이 즉시 혹은 빠른 시일 내에 구현할 수 있는 실용적인 디자인 개념을 가지고 떠났으면 합니다. 장기적으로 작업할 현실적인 계획 그리고 목표와 균형을 이루어서 말입니다. 그들이 어느 "교과서"적 연구 방법이 기업적 맥락에서 작동하고 작동하지 않는지 더 좋은 감각을 가지기를 바랍니다. 그리고 한가지 작업틀을 가지고 돌아가 조직에서 기업적 팀을 이루어 IA 문제들을 해결하는데 지침이 되기를 바랍니다.
스튜어트: 바깥 경기를 생각해볼 때 어떻습니까? 사용성과 IA에 돈을 쓸 능력이 될 사람들이 있을까요?
로젠펠드: 불경기이기는 하지만, 적어도 미 연방 정부는 IA에 어느 정도는 지출을 하고 있습니다. 왜 그런지는 묻지 마세요. 거대 기업들초차도 IA 문제들에 접근하는데 필요한 최소한의 자금을 모으고 있는 듯 합니다. 그냥 그들은 소프트웨어 도구들에다 돈을 지출하려고 하지 않을 따름입니다. 전문가를 초빙함으로써 그런 투자가치를 높이려고 더욱 더 노력하고 있습니다. 사실, 많은 기업들이 현재 전업제 IA 전문가들을 간부로 채택하고 있다는 사실에 놀랐습니다. 이런 것들을 볼 때, 낙관적이란 생각이 들지 않습니까?
크럭: 상당히 많은 사람들부터 들은 이야기에 의하면 경기가 여전히 아주 힘들다고 합니다. 이제서야 생각보다 많은 회사들이 사용성에 노력을 기울여야 한다는 사실을 깨닫고 있지만, 프로젝트 예산의 표준 라인에 들기에는 여전히 거리가 멀다고 생각합니다. 들은 바로는 많은 회사들이 관심을 표명하고 사용성에 관하여 문의하지만, 실제로 거기에 돈을 쓰는 결정을 내리는데 이르지는 못하는 것 같습니다.
사용성에 돈을 쓰는 회사들은 웹에 방대한 투자를 하고 있는 거대 회사들이고, 그 보다 작은 회사에서는 관리자들이 이전에 사용성에 경험이 있고, 그냥 비용을 지출하는 대신, 디자인 과정을 실제로 거대회사들 보다 더 쉽고 빠르게 만들 수 있다는 것을 알고 있는 경우에 사용성에 비용을 지출합니다.
TAG :
최신 콘텐츠