디스트릭트가 마이크로소프트 Innovation Parner Day에 Surface와 함께 출격합니다.
- 행사가 1월로 연기 되었습니다.

http://myrsvp.co.kr/ms/partner_day_20081216/

 

 

WRITTEN BY
ONESTONE

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Card Sorting

UX 2008. 8. 18. 20:30

카드소팅(Card Sorting)

카드 소팅은 어떤 정보를 분류하고 구조화하는 빠르고, 싸고, 신뢰성있는 방법입니다.
웹사이트를 만들때 인포메이션 아키텍쳐(IA, Infomation Architecture)를 잘 잡아야 합니다. 경험 디자인 요소라는 책에서는 구조 단계에서 인포메이션 아키텍쳐를 설계합니다. 쉬운 예를 들자면 웹 사이트의 메뉴를 만들 때 고려가 되어야 합니다. 어떤 메뉴가 어떤 상위메뉴에 포함이 되어야 하는지를 결정할 때 이 카드 소팅 방법을 사용하면 됩니다. 또한 네비게이션이나 분류를 만들 때 적당한 방법이죠. 사용성 테스트(Usability Test)에도 사용할 수 있습니다.

사용자가 말로 표현하지 못하는 작업에 대한 그룹핑, 정렬,이름짓기에 도움이 됩니다.

사용자의 멘탈모델에 대한 이해를 할 수 있습니다.

카드소팅의 절차 

 1) 적당한 크기의 카드를 준비하고 카드 마다 분류하고자 하는 내용을 적습니다.
 2) 카드 소팅에 참여할 참가자를 모집합니다.
 3) 참가자에게 카드를 보여주고 인터뷰를 진행합니다. (관련있는 카드끼리 그룹핑을 하게 하는 등의 방법)
 4) 그룹핑 된 카드에 적절한 이름을 짓게 합니다.
 5) 수집된 데이터를 분석

아래 그림을 보면 어떤 방법인지 금방 감이 옵니다. 저런 카드를 늘어놓고 관련된 것 끼릭 묶어보면 어떤 규칙이 발견되겠죠. 카드소팅으로 최종의 구조를 결정하지는 못하겠지만 어떤 문제를 해결하는 실마리는 제공해 줄 것 같습니다.

단순한 방법 같이 보이지만 데카당스 님의 글과 첨부된 계획서를 보면 카드소팅을 제대로 한다는 것이 쉬운 일만은 아닌것 같습니다. 계획서를 보면 참여자 리크루팅, 테스팅 룸의 배치, 테스트용 판의 제작 방법, 관찰표, 실행 프로세스, 스텝의 업무분장 등 정말 세밀한 계획 속에서 카드 소팅이 이루어 짐을 볼 수 있습니다. 와우! 대단합니다. 이 정도면 카드소팅이 싸고 간단한 방법이라는 것이 취소해야겠습니다.

사용자 삽입 이미지

카드소팅에 대한 영어로 된 좋은 글
http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide


WRITTEN BY
ONESTONE

트랙백  0 , 댓글  0개가 달렸습니다.
secret

창의적인 아이디어를 발굴하고 의사결정을 하기 위한 도구인 '브레인스토밍'.
새삼스러울 것없이 자주 사용하는 방법이지만 한번 정리를 하고 싶습니다.

1. 방법
 - 구성원들이 아이디어를 머리속에 폭풍이 몰아치듯이 자유롭게 말하고 정리한다.
 - 아이디어에 대한 판단은 뒤로 미루고 가능한 많은 아이디어를 개진한다.
 - 문제설정 → 인원구성 → 문제제시 → 원칙확인 → 연습 → 진행 → 종결 → 아이디어 낭독 → 추가기록 → 정리 및 활용

2. 규칙
 - 개진된 아이디어를 비판하지 않는다.
 - 자유로운 분위기를 만들고 유도한다.
 - 질보다 양
 - 아이디어를 통합하고 개선한다.

이렇게 정리를 하고 보니까 모든 회의나 협의의 기본이라는 생각이 드네요. 오늘 처음으로 해본 "페이퍼 프로토타이핑(Paper Prototyping)"도 기본 바탕에는 저 4가지 규칙이 깔려 있네요.

저 4가지 규칙보다 우선시 되는 것이 있습니다.
팀원들 간의 "신뢰와 존경" 이겠죠. 말이 좋아서 신뢰와 존경이지 팀원들 서로가 그런 느낌을 갖기가 쉽지 않은 것 같습니다. '저 사람 참 존경스럽다. 같이 일할 맛이 난다." 이런 느낌을 받기까지 시간이 좀 필요하겠죠.

브레인스토밍을 가장 잘하는 기업은 어디일까요? IDEO라는 회사라네요. "유쾌한 이노베이션"이라는 책을 구입했습니다. 그 책의 이야기가 바로 IDEO라는 기업의 이야기죠. 다 읽으면 리뷰를 써야겠습니다.

Brainstorming (IDEO)



WRITTEN BY
ONESTONE

트랙백  0 , 댓글  1개가 달렸습니다.
  1. 리뷰를 기다립니다~
    리뷰 전에 책 살지도 모르겠어요. ^^
secret

프로세스가 잘 정의되어 있지 않고 팀원들 각자의 역할이 잘 분할되지 않은 팀에서는 협업의 문제가 자주 발생하죠. 특히 창작과 창조가 주요한 업무 영역인 디자인은 어떤 환경을 만들어 주고 어떻게 일을 주고 협업을 하느냐에 따라서 결과물에 많이 달라집니다. 쉬운 얘기가 아니죠.

한 잡지에 기고된 박병천 더 브레인컴퍼니 대표이사의 글이라고 합니다. 디자이너와 일을 할 때 어떤 마음가짐을 가져야 하는지 잘 표현이 되어 있습니다. 간섭형 기획자에서 벗어나 좋은 기획자가 되어야 겠습니다.


디자인 기획자와 디자이너는 좋은 파트너쉽을 형성해야 한다.

기획업무보다는 영업활동에만 치우쳐 있는 영업형 기획자,
클라이언트의 지시나 자료를 전달해 주는 정도의 정보전달형 기획자,
표현소재나 방법까지 과도하게 챙겨주는 간섭형 기획자는
디자이너의 창작활동에 큰 도움을 주지 못한다.

좋은 기획자는 디자이너로 하여금 자신이 궁극적으로 해결해야 할 과제가 무엇인지를 정확히 알도록 해 준다.
그리고 디자이너가 몰입해야 할 표현의 영역이 어디인지 그 좌표를 제시해 준다.

더 좋은 기획자는 디자이너가 표현을 실마리를 쉽게 찾도록 해 주고
아이디어가 꿈틀거리도록 유도해 주는 사람이다.

- 박병천(더 브레인컴퍼니 대표이사)

WRITTEN BY
ONESTONE

트랙백  1 , 댓글  1개가 달렸습니다.
  1. 디자인 기획자로서의 방향을 제시해 주는 좋은 글이네요. ^^
    다이어리에 적어두고, 생각날 때마다 꼭 읽어야 하겠습니다.
secret
사용자 삽입 이미지

 경험디자인의 요소(The Elements of User Experience)
 (성공하는 웹 사이트를 위한 사용자 중심 디자인. User-Centered Design for the web)

 제시 제임스 게러트(Jesse James Garrett) 지음 / 방수원 옮김


제시 제임스 게러트는 UXFactory 황리건 과장님이 뽑은 UX 분야의 가장 유명한 10인중에 6등 하신 분입니다.^^ 이 책의 첫 느낌은 UX 분야의 고전 같은 느낌입니다. 전체 190페이지로 커피 한잔을 마시는 시간으로 읽을 수 있는 책입니다.

우선 경험 디자인 요소(The Elements of User Experience)의 원본을 한번 살펴보세요. 이 그림은 웹 디자인 컨설팅 회사의 정보 설계자로 일하면서 쌓은 경험을 2000년 3월 30일에 최종 정리한 그림이라고 합니다. 가만 있자 2000년이면 UX라는 말이 없었을 것 같고 웹이라는 것도 어색할 시절 아니던가요? 어째든 저 그림을 바탕으로 이 책은 2003년에 처음 출판되었습니다. 고전이라고 할 만 합니다. 책에서 예제로 나오는 사이트도 오래된 느낌이 나고 있습니다.

1-2년전부터 유행을 하고 있는 UX라는 말은 뭔가 새로운 것, 기존에 없던 것이라는 느낌이 강했습니다. 디자인이 연관되어야 할 것 같고 창의력과 깊은 관련이 있지 않을까? 개발하고는 조금 거리가 있을 것 같기도하고. 이 책을 읽으면 UX에 대한 애매한 느낌이 사라지고 실제 과제에 적용을 할 수 있겠다는 자신감이 살짝 생깁니다.

이 책에서는 사용자의 경험을 높이는 웹사이트를 만들기 위한 5가지 단계, 전략 - 범위 - 구조 - 윤곽 - 표면에 대한 설명이 나와 있습니다. 이 5단계는 아래(전략)에서부터 시작되어 마지막 표면 단계를 거치면서 완성됩니다.

전략
 - 사이트를 운영하는 사람들이 제시하고 싶어하는 것과 사용자들이 그 사이트에서 얻고 싶어 하는 것
 - 사업의 목표, 사이트의 목표, 브랜드 아이덴티티(Brand Identity)
 - 사용자에 대한 분석, 요구사항 수집

범위
 - 전략에서 수립한 사용자의 요구와 사이트의 목적을 어떤 콘텐츠와 기능으로 웹 사이트가 사용자들에게 제공될지에 대한 구체적인 요구사항
 - 사용자 시나리오, 기능 세부 사양, 콘텐츠 요구사항, 요구사항에 우선순위
 - 소프트웨어 인터페이스로의 웹 : 기능적 세부사항 / 하이퍼텍스트 시스템의로서의 웹 : 콘텐츠 요구사항

구조
 - 인터렉션 디자인 : 있을 수 있는 사용자의 행동을 설명하고 시스템이 그러한 태도를 어떻게 수용하고 반응할 것인가?
 - 인포메이션 아키텍쳐 : 사용자들이 사이트 콘텐츠들 사이를 효과적이고 효율적으로 이동할 수 있게 해주는 구성과 계획
 - 소프트웨어 인터페이스로의 웹 : 인터렉션 디자인 / 하이퍼텍스트 시스템의로서의 웹 : 인포메이션 아키텍쳐

윤곽
 - 네비게이션 디자인 : 사용자들이 어떤 장소로 가는 능력을 제공하는 일
 - 인터페이스 디자인 : 사용자들이 무언가를 하는 능력을 제공하는일
 - 인포메이션 디자인 : 사용자들에게 관념을 전달하는 일
 - 소프트웨어 인터페이스로의 웹 : 인터페이스 디자인 / 하이퍼텍스트 시스템의로서의 웹 : 네비게이션 디자인,

표면
 - 사용자들이 제일 먼저 마주치는 비주얼 디자인
 - 배치, 시선, 컬러, 타이포 그래피, 스타일 가이드

이 5단계를 차례대로 거치면서 사이트의 목표와 같은 큰 개념에서 마지막 비주얼 디자인까지 어떤 생각을 해야하고 어떤 과정을 거쳐야 하는지 아주 잘 정리가 되어 있습니다. 특히 UX 라고 하면 비주얼 디자인과 사용자 인터렉션에 중심이 있다고 생각했지만 인포메이션 아키텍쳐와 콘텐츠에 대한 요구사항 또한 절반을 차지하는 요소라는 것을 알았습니다.

경험디자인 요소는 웹을 개발하거나 디자인하거나 기획하는 모든 분들이 읽어보기를 권합니다. 서로에게 어떤것을 요구해야 하는지 팀작업은 어떠한 순서로 어떤 내용을 다뤄야 하는지에 대한 명확한 가이드를 제공하고 있습니다. UX에 관심이 있다면 필독!

---------------

사실 2주전에 프로젝트 리더에게서 "추가로 개발하는 사이트에 대해서 충분히 논의를 했으니 스토리보드를 만들어와라!"라는 명을 받았습니다. 스토리보드를 다른말로 하면 와이어프레임이라고도 하던데요. 실제 개발/디자인에 들어가기 전에 디자이너/개발자/관리자/기획자 간의 소통을 담당하는 놈이죠.

막막합니다. 아이디어가 있고 사이트가 제공할 것들이 명확하고 이런 저런 요소들이 눈앞에 아른 거리기는 하는데 막상 그 생각들을 정리하고 종합해서 최종 스토리보드를 만든다는 것이 쉽지만은 않습니다. 아직 디자이너와 함께 일할 개발자도 정해지지 않은 상태에서 저는 "경험 디자인 요소"를 손에 들었습니다.

이 책을 믿고, 손에 들고 5가지 단계를 따라가고 있습니다. 오홋 매우 만족 스럽습니다. 회사 일이라서 구체적인 내용을 포스팅 할 수는 없지만 조만간에 한번 정리를 해서 올려보도록 하겠습니다.

WRITTEN BY
ONESTONE

트랙백  0 , 댓글  1개가 달렸습니다.
  1. 실제로 적용하는건 늘 어렵죠..호홋...
    함 간략하게 스토리보드로 셈나해주세욤~
    이게 이부분이고 이렇게 정리했고...ㅎㅎ
secret

아래 그림은 언젠가 이메일을 통해서 뿌려졌던 사용자 요구사항에 대한 그림입니다. 개발자라면 무척이나 공감하는 이 그림은 당시 빠르게 퍼져나갔었죠. 처음에는 그냥 공감이 가는 웃음으로 대했지만 현실을 너무나도 잘 반영한 이 그림을 보고 한참을 고민했었습니다.

사용자 삽입 이미지


지난주에 프로세스에 대한 교육을 받는 중에 이 그림이 다시 등장을 했습니다. 강사님은 그림의 한컷 한컷을 집으면서 사용자 요구사항 수집의 중요성을 강조했었습니다.

  • 최초에 고객은 3단짜리 나무판이 있는 그네를 얘기했다.
  • 설계자의 디자인은 고도의 기술을 사용하여 설계를 하는 경향이 있다. 그림에서는 나무가 공중에 떠있고 두개의 가지가 나무를 받치고 있는 멋진 기술을 이용한 설계를 보여주고 있다.
  • 프로그래머는 설계자의 의도를 파악하지 못하고 자신이 이해하는 수준으로 개발을 진행하고 코드는 짜임새 있지 못해서 프로그래머의 그네처럼 줄이 축 늘어져 그네의 역할을 하지 못한다.
  • 프로젝트가 끝났을 때 쓸만한 문서는 남아 있지 않다.
  • 하지만 사용자가 진정 원한것은 타이어가 묶여있는 그네였다.
  • 그러므로 개발을 시작하기 전에 사용자의 요구사항이 충분히 수집이 되어야 한다.
  • 기획팀이 요구사항 정의서를 완벽하게 만들어 오기 전에는 개발을 시작하지 말 것.

이런식이 었습니다.

사용자 요구사항에 얼마나 중요한지에 대한 강의를 잘 이해를 하면서도 한편으로는 현실을 반영하지 못한 정말 교과서에만 나오는 얘기를 해서 실망을 했었습니다.

강의 내용에는 실전에서 통하지 않는 '사용자 요구사항에 대한 몇 가지 환상'이 있었습니다. 아래 3가지가 바로 그것 입니다.

  • 환상 1 : 프로젝트의 시작단계에서 사용자 인터뷰를 통해서 요구사항을 수집할 수 있다.
  • 환상 2 : 요구사항은 개발이 시작되기 전에 기획단계 또는 영업단계에서 확정이 되어서 개발팀에 전달 될 것이다.
  • 환상 3 : 요구사항은 개발 초기에 정해지면 절대 변경되면 안된다.

위의 그림에서 한가지 더 주목할 것이 있습니다. 사용자가 진정 원했던 '타이어 튜브 그네'는 제일 마지막에 나온다는 것입니다. 사용자는 최초 요구사항 수집 단계에서 3단짜리 나무 판이 있는 그네를 설명했습니다. 사용자는 자신이 진정 원하는 것을 말하고 있지 않습니다.

실전에서도 그렇습니다. 사용자 또는 고객은 개발이 시작되기 전에 정확한 요구사항을 주지 못합니다. 개발이 진행되면서 그 요구사항이 정돈되고 구체화되는 경향이 있습니다. 특히 개발 중간에 데모가 있으면 데모가 끝남과 동시에 요구사항을 마구 쏟아내기도 합니다. 최악의 상황에서는 개발이 종료되는 시점에 아주 중요한 요구사항을 내놓기도 하죠.

이런 상황이 사용자와 우리의 고객들이 뭘 잘 모르거나, 개발자를 괴롭히고 싶어하거나, 프로젝트를 망치게 하기 위해서 또는 원래 못된 성격이라서 발생한 것이 아닙니다. 사용자는 원래 그렇습니다. IT 개발 경력 7년동안 일관되게 그랬었습니다. 우리 개발자들은 그런 현실을 인정해야 합니다.

사용자 요구사항을 이렇게 표현하고 싶습니다.

사용자로 하여금 자신이 진정으로 원하는 것을 말하게 하는 과정, 사용자 자신이 진정으로 원하는 것이 뭔지를 찾을 수 있도록 도와주는 과정이 바로 개발이다.

사용자가 개발의 중간에 요구사항을 추가로 내거나 중요한 변경을 해도 결코 노여워하거나 슬퍼하지마세요. 그들은 원래 그랬으니까. 기획팀에서 영업팀에서 요구사항 문서를 부실하게 만들어 줘도 이해해 주세요. 개발 과정에서 구체화시키고 완성시키면 되니까.

사용자 요구사항 수집에 대한 현실을 인정해야 합니다. 우리의 건강을 위해서 그리고 프로젝트가 성공하기 위해서...


WRITTEN BY
ONESTONE

트랙백  1 , 댓글  4개가 달렸습니다.
  1. 아주 공감이 가는 얘기네요.
    가장 황당한 경우가 프로젝트는 진행되는데 우리의 고객이 누군지도 모르는 상태죠..- _ -;
    결국 고객도 우리가 되고 개발도 우리가 하고....
    완성품을 보고 만족하는 사람은 아무도 없던...때가 떠오릅니다..ㅎㅎ
    타이어 그림이 의미하는 바가 뭐였는지 그때는 몰랐는데 이제 이해가 가네욤~
    재밌는 글이었어요~:D
    • 고객이 우리가 되고 개발도 우리가 하고 ...
      그런경우도 있군요.
      취미생활도 아니고 ...
  2. 마지막에 정리하신 대목이
    정신과 의사(혹은 카운셀러)들이 갖춰야 덕목과 여러모로 흡사하네요.
    대화를 통해 환자가 말하고 싶게 만들고,
    모든 것을 쏟아내도록 유도하는 스킬이 중요하죠.

    처음에는 '나를 정신병자 취급하지 말아'라는 식으로 말을 하던 환자가
    결국에는 'Damn it!'을 외치면서 그동안 억압했던 감정을 밑바닥까지
    표출해 내는 장면이 떠오르네요.

    그렇다고 고객이 환자라는 뜻은 아니예요.
    (서구 사회에서는 정신과 상담을 받는게 평범한 일이죠.)
  3. 오, 와닿네요. 개발자는 아니지만, 공감이 갑니다!
secret