태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


'기획'에 해당되는 글 8건

  1. 2015.04.07 [독후감] 웹 기획자가 알아야 할 서비스 글쓰기의 모든 것 (12) by 위승용 (uxdragon)
  2. 2011.09.06 [Mobile] 안드로이드 위젯 기획시 고려사항 (10) by 위승용 (uxdragon)
  3. 2010.04.27 암기 프로그램, 왜 이런건 없는거야?? (2) by mango01
  4. 2010.04.23 낙서에 가장 적합한 디바이스는? (7) by mango01
  5. 2010.04.09 “퍼소나가 유니버설 디자인 제품에서도 활용 될 수 있을까요?” (3) by mango01
  6. 2010.03.20 Workflow 협업하여 함께 그리기! 3-day! (2) by mango01
  7. 2010.03.20 좋은 네비게이션 레이블(lable)의 조건 by 위승용 (uxdragon)
  8. 2010.03.19 멘탈모델-체계적인 사용자 조사계획 수립하기 by 전성진
2015.04.07 07:50

[독후감] 웹 기획자가 알아야 할 서비스 글쓰기의 모든 것




웹 기획자가 알아야 할 서비스 글쓰기의 모든것이라는 책을 읽었습니다. NHN의 테크니컬라이터가 쓴 책입니다.

이 책은 개발자나 디자이너가 보는 UI 문서가 아니라, 사용자들이 보는 'UI 텍스트' 에 대한 글쓰기 방법이 기술되어 있습니다. (UI 텍스트: 웹 서비스나 애플리케이션 사용자가 이용하는 버튼, 메뉴, 대화상자, 입력란, 확인란 등과 같은 UI 요소에 적힌 텍스트와 오류 메시지들을 지칭함)

pxd같은 에이전시의 경우 별도의 전문 테크니컬라이터가 없기 때문에 평소 UI 기획자가 테크니컬 라이팅에 대해서도 고민을 하게 됩니다. 이런 관련 지식들을 배우고 싶었는데 적당한 시점에 좋은 책이 나왔네요.


새롭게 배운 부분 위주로 발췌한 내용 공유드립니다. 평소에 내가 쓰던 표현중에 무의식적으로 잘못 쓰고있던 표현이 있는지 비교해보면서 읽어보시면 더 흥미로우실것 같습니다.






1. 웹 서비스 글쓰기의 기본

1.1. 정확하게 쓴다.

필요한 정보를 생략하지 않는다. (p.23)

"UI 텍스트는 문서를 쓸 때와는 다르게 짧은 문장으로 필요한 내용만 정확하게 써야 한다. 그런데 문장을 줄이다 보면 필요한 정보까지 생략해 버리는 일이 생긴다. 필요한 정보가 생략되면 그 뜻을 제대로 이해하지 못할 수 있다. 따라서 작성한 텍스트를 여러 번 읽고 빠진 내용은 없는지 반드시 확인하고 고쳐야 한다."


정확하게 쓴다. (p.29)
"Internet explorer와 Firefox는 고유한 제품 이름이므로 정해진 그대로 써야한다.” 
레이블의 공간이 부족해서 부득이하게 약어를 써야하는 상황이 생긴다면 어떻게 해야할지에 대한 궁금증이 생기더군요.


1.2. 보편적으로 쓴다.

외국어, 한자어는 한글로 바꾼다. (p.40) 
보통 기획을 할때 화면상에 외국어를 많이 쓰는 경향이 있는데 이해하기 쉽게 한글로 써야겠다는 생각이 들더군요. 특히 More 버튼.

My top 30 → 자주 들은 음악 30
Help → 도움말
FAQ → 자주 묻는 질문
More → 더 보기
Top → 맨 위로
Sync → 동기화 


1.3. 일관되게 쓴다.

마우스 동작 표현 (p.49) 
기획을 하다보면 UI 텍스트에 드래그 앤 드랍 같은 용어를 쓰는데 주의해야 겠습니다.

마우스커서 → 마우스포인터
마우스 왼쪽 버튼 → 마우스 버튼
마우스우클릭 → 마우스 오른쪽 버튼 클릭
드래그 앤 드랍 → 끌어다 놓기

체크 → 선택


UI 요소 표현 (p.56)

"UI요소를 가리킬 때는 UI 요소의 이름만 쓰고 '드롭다운 목록 상자'와 같은 용어는 쓰지 않는다."
사용자 설정 보기 드롭다운 목록 상자 → 사용자 설정 보기 


모바일 동작 표현 (p.58) 
"운영체제와 제품에 공통으로 사용할 수 있는 용어를 쓰라."

누르기
두 번 누르기
끌기
길게 누르기
쓸어 넘기기
손가락 오므리기, 벌리기 


1.4. 간결하게 쓴다.


불필요한 단어를 넣어 늘어 쓰지 않는다. (p.64)

정말 삭제하시겠습니까? 같은 UI 텍스트는 저도 예전에 썼던 기억이 있습니다.

정말, 참, 매우, 성공적으로 X
정말 삭제하시겠습니까? → 삭제하시겠습니까?
메일을 성공적으로 보냈습니다. → 메일을 보냈습니다.


조사는 꼭 필요할 때만 쓴다. (p.67) 

채택을 하지 → 채택하지
해지를 한 후 → 해지하지
가입을 할 수가 → 가입할 수


1.5. 형식을 갖춰 쓴다.

메뉴에 줄임표를 넣는다. (p.71) 
"버튼이나 메뉴를 클릭했을 때 바로 기능이 실행되지 않고도 다른 대화 상자나 창이 나타나 추가 정보를 입력해야 할 때는 버튼이나 메뉴 이름 뒤에 줄임표(...)를 넣는다."


2. 웹 서비스 글쓰기의 실제

2.1. 권장표현과 올바른 표기

한자식 표현은 자제한다. (p.78) 

우선적으로  우선으로, 먼저 

아이디가 정상적으로 등록되었습니다. → 아이디가 등록되었습니다.


번역 투를 쓰지않는다. (p.79) 

Have 가지다.
인증을 가진  인증을 사용하여


Want, Need 원하다, 필요하다.
로그인하기 원하시면  로그인하려면


Through, Via 통해
댓글을 통해  댓글로

자동완성을 위해  자동완성에 등록할 

사용가능한  사용할 수 있는


사이시옷은 언제 써야 하나 (p.93) 
평소 많이 헷갈리는 표현입니다. 특히 개수...


최대값, 최소값  최댓값, 최솟값,  

꼬릿말 -> 꼬리말
갯수 -> 개수


외래어 표기는 어떻게 하나 (p.95) 
이 내용을 보고 좀 충격적이었습니다. 섬네일이 맞는 표현이라고 하는군요.

썸네일  섬네일 

메세지  메시지


2.2. 띄어쓰기

띄어쓰기 기본 원칙. 단어와 단어 사이는 띄어쓴다. (p.98) 
"서비스의 버튼이나 메뉴, 탭 이름등은 메시지를 표시할 공간이 부족한 경우 붙여 쓸 수 있음. (서비스 전체에서 용어별로 띄어쓰기 일관성을 유지하는 게 중요.)"


작은창  작은 창 

그때 그때  그때그때 

찾아 본  찾아본 

지난 주  지난주 

살펴 보시기  살펴보시기 

전자 우편  전자우편 (둘 다 가능함) 

국어사전/영어사전/중국어사전 (띄어쓰기, 붙여쓰기 둘 다 가능함)


조사는 앞말에 붙여 쓴다. (p.101) 
정확도순 같은 표현은 가끔씩 띄어쓰기를 했던것 같은데 이 참에 제대로 배웠습니다.


최대 100개 까지  최대 100개까지 

페이지 뿐만  페이지뿐만 

쇼핑몰 별, 가격 별, 스팩 별  쇼핑몰별, 가격별, 스팩별 

정확도 순, 인기 순, 최신 순, 가나다 순  정확도순, 인기순, 최신순, 가나다순 

달력 형  달력형


의존명사는 앞말과 띄어 쓴다. (p.106) 


홍길동님  홍길동 님 

삭제시  삭제 시, 삭제하면 

네이버me등의  네이버me 등의 

한개  한 개


2.3. 문장부호와 특수 기호

마침표 (p.110)  

저는 평소에 마침표를 항상 긴밀하던 긴밀하지 않던 마침표를 각각 따로 썼었는데, 이런 규칙이 있다는 걸 처음 알았습니다.
연월일의 경우에도 마침표를 쓰고 한칸 띄어쓰기를 한다는 사실도 배웠습니다.


"괄호 안의 문장이 앞 문장과 내용상 긴밀한 관계일 경우 두 문장의 마침표를 묶음"
개수가 많을 때 사용한다(10개 미만일 경우에 사용).


"괄호 안의 문장이 앞 문장과 긴밀한 관계가 아닐 경우 마침표를 각각 따로 씀"
개수가 많을 때 사용한다.(별첨 참조.)
개수가 많을 때 사용한다.(별첨 참조)


"연월일의 마침표는 띄어쓴다. ‘일’ 다음에 마침표를 빠뜨리지 않도록 주의."
2013.03.27  2013. 03. 27. 


쉼표 (p.115) 
"쉼표 앞은 붙여쓰고, 뒤는 한 칸 띄어 쓴다."
아이디,이름,주민등록번호  아이디, 이름, 주민등록번호


"특별히 끊어 읽을 필요가 없으면 쉼표를 사용하지 않음."
묻고, 답하고, 알려주세요.  묻고 답하고 알려주세요.


가운뎃점, 빗금 (p.119, 121) 
날짜는 빗금을 쓰지 않는다는군요;


"가운뎃점은 열거된 여러 단위가 대등하거나 밀접한 경우, 빗금은 대립되는 경우나 분수를 나타내는 경우 사용."
"빗금 앞뒤에 빈칸을 두지 않는다."


만화・웹툰 서비스, 학습・교육
수입/지출, 클라이언트/서버
3/4 분기


"날짜는 빗금을 쓰지 않는다."
12/25  12월 25일, 12.25.


괄호 (p.125)
"UI 텍스트를 쓸 때에는 되도록 괄호를 쓰지 않는다."
"불필요하게 괄호를 쓰지 않는다."


(이동 중)  이동 중…


"괄호 앞에는 빈칸을 두지 않음, 괄호 안의 내용이 긴밀한 관계일 경우 마침표는 괄호 밖에 찍음."
기본 검색의 결과 범위를 줄이고자 할 때 사용한다(상세 검색의 기능이다).


"괄호 뒤에 오는 조사는 괄호 앞에 있는 명사와 호응한다."
메일주소(메일함)을  메일주소(메일함)를


대괄호 (p.129)
"메뉴 이름과 창 이름, 버튼 등의 UI 텍스트를 구별하는 서식이 없을 경우 대괄호를 사용한다."
계속하시려면 ‘다음'버튼을 눌러주세요.  계속하시려면 [다음]을 클릭하세요.


쌍점 (p.136)
쌍점 같은경우에도 제가 평소에 쓰는 규칙과 달라서 깜짝 놀랐습니다.


"쌍점 앞은 붙여쓰고 쌍점 뒤는 한 칸 띄어 쓴다."
정렬기준:날짜순  정렬 기준: 날짜순


"시간을 표시할때는 쌍점을 붙여서 쓴다."
오전 10:20


물결표 (p.138) 
"물결표는 앞뒤에 빈칸을 넣어 한 칸씩 띄어 쓴다."
월요일~금요일  월요일 ~ 금요일


하이픈 (p.139)
"얼마에서 얼마까지의 의미로 사용하지 않는다."
6자리 - 15자리의  6자리 ~ 15자리의


"연월일을 표기하는데 쓰지 않는다."
2013-04-04  2013. 4. 4. 또는 2013년 4월 4일


줄임표 (p.143)
"여섯 점을 찍는 것이 원칙이나 마침표를 세번 찍는 것(…)도 허용함."


기타 특수 기호 표기 (p.148) 


"사칙연산을 나타내는 수학 기호를 쓸 때에는 숫자와 기호 사이에 빈칸을 넣는다. "
"단, 나누기 기호 대신 빗금(/)을 사용할 때는 기호 앞뒤에 빈칸을 두지 않는다."
"곱하기 기호는 소문자 x로 표기한다. "
"곱하기 기호로 별표(*)를 사용하지 않는다. "


"기호 앞뒤에 빈칸을 두지 않는다. "
스포츠 & 톡 베스트 10  스포츠&톡 베스트 10


2.4. 숫자와 단위 표기

숫자와 단위 표기 기본 원칙 (p.154)
"숫자 범위뒤에 단위를 쓸 때 각 숫자의 단위가 같으면 마지막에 오는 숫자 뒤에만 단위를 쓴다."
10MB ~ 20MB  10 ~ 20MB 

1개 ~ 100개  1 ~ 100개


12시는 오전 또는 오후에 포함되지 않는다.
오전 8시 ~ 오후 12시  오전 8시 ~ 밤 12시


영업 시작일 다음날 오전 1시에 영업이 끝난다면 오전 1시 대신 25시와 같이 쓰기도 함.


전화번호 표기 (p.166)
전화번호 표기 같은경우에도 휴대전화와 일반 전화 방식을 구별하지 않고 썼었는데, 구분이 있다는 사실을 처음 알았습니다.


"국번과 가입자 개별 번호는 하이픈(-)으로 구분하고 하이픈 앞뒤에는 빈칸을 두지 않는다."
(02) 000 0000, 02) 000 0000, 02-000-0000  (02) 000-0000


"휴대전화의 경우 통신망 식별 번호는 국번 앞에 하이픈으로 구분해서 쓴다."

(010) 0000-0000  010-0000-0000, +82-10-0000-0000


2.5. 전 세계 사용자를 고려한 가이드

"다국어를 지원하는 서비스를 기획 할 경우 언어별로 길이가 다르므로 UI 설계를 할때 이점을 잘 고려해야 한다.” (p.190)


"국가별로 날짜와 시간을 다르게 사용하므로 이 점을 고려햐여야 한다." (p.197)
한국/중국/일본과 미국 지역은 오전, 오후 표기법을 사용하며 유럽/남미 지역에서는 24시를 사용합니다. 그리고 연/월/일 표기법이 다름을 알 수 있습니다.


한국/중국/일본: 2015년 3월 20일, 오후 8시 10분
미국 : March 20, 2015, 8:10pm
유럽/남미 : 20 mars, 2015, 20:10


감사합니다. 


[참고##도서##]



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 12
Ad Test...
2011.09.06 09:00

[Mobile] 안드로이드 위젯 기획시 고려사항


글을 시작하며...
최근 회사 동료로부터 안드로이드 위젯 프로젝트 관련 노하우 공유 요청을 받았습니다. 경험을 공유하다 보니, 이와 관련해서 생각을 정리해보고 싶은 마음이 들었습니다.

본 블로깅을 통해 안드로이드 위젯 관련 프로젝트를 시작하시는 신입 분들이나, 실무경험이 상대적으로 적은 학생분들에게 도움이 되었으면 좋겠습니다. (저보다 많은 경험이 있으신 분들은 의견을 보태주시면 저같은 UI 기획자가 배울 수 있는 밑거름이 될 것 같습니다.) 또한 다음 고려사항들은 순수히 제 의견이며 논란의 여지가 충분히 있으므로 이점도 감안해 주시고 봐주세요.

[그림1] 추억의 햅틱 위젯

[그림2] 안드로이드 위젯
 
 
위젯은 무엇인가?

웹 전문가인 '힌치클리프' 는 위젯을 웹에서 실행되는 작은 어플리케이션이라고 정의하였습니다. 위젯의 사전적 의미는 실용적인 목적으로 사용되는 작은 기계 또는 장치를 말하는 것으로, 주로 새롭게 만들어졌거나 신기한 장치, 또는 이름을 알 수 없거나 생각나지 않는 소형 장치, 부품, 도구를 일컫는 단어로 사용되고 있습니다. 또한 위젯의 동의어로 자주 사용되는 단어로 가젯이 있는데요. 위젯과 가젯의 어원이 정확히 알려진 바는 없지만 웹스터 사전에 등록된 시기를 볼 때 오래 전부터 사용된 단어인 것으로 추정됩니다. 또한 위젯을 뱃지(badge), 모듈(module), 버튼(button) 등으로 부르기도 합니다. (출처 하단 명기함) (아이폰같은 경우 위젯과 어플리케이션의 경계가 모호하기는 합니다. 이 점은 논란의 여지가 있으나 본 블로깅에서는 다루지 않습니다.) 

본 블로깅에서는 안드로이드 위젯 기획시 고려사항에 대해서 다룹니다.


안드로이드 위젯 기획시 고려사항

1. 위젯의 핵심 고려사항은 유용성과 크기다.
다양한 위젯 사이즈중에서 어떤 사이즈를 선택하는 것이 좋을까요? 저는 유용성과 크기를 고려해서 설계해야 한다고 생각합니다. 위젯을 설치할 확률은 유용성에 비례하고 크기에 반비례하지 않을까 생각합니다. 같은 유용성을 갖는다면 가능하면 작게 만드는 것이 좋겠고요, 그렇다고 해서 고유의 유용성을 해치면서까지 작게 만들다가는 실패할 여지가 있습니다.  (위젯 크기와 위젯의 유용성에 따른 위젯 등록의 상관관계에 대해서 조사해보고 싶은 생각은 드네요.) 

[그림3] 안드로이드 portrait size

[그림4] 안드로이드 landscape size


2. 터치 영역을 고려해야 한다.
위젯은 그 크기가 어플리케이션에 비해 상대적으로 작으므로 터치 영역을 잘 고려해서 설계해야 합니다.
애플 Human interface guideline을 보면 최소 터치 영역이 44px임을 확인할 수 있습니다. 윈도우폰 UI 가이드라인을 보면 터치 영역을 9mm(34px) ~ 7mm(26px) 사이로 권장하고 있습니다.

현재 안드로이드 위젯 가이드라인에는 최소 터치 영역에 대한 가이드라인이 없으므로, 아쉬운대로 애플 HIG나 윈도우폰 UI 가이드라인을 참조해야 겠습니다.

[그림5] Touch target size


3. 기왕이면 기능은 단순한게 좋다.
위젯은 어플리케이션이 아닙니다. 기왕이면 단순한게 좋습니다. 위젯을 어플리케이션처럼 생각해서 기능에 집중하기 보다는 Short cut의 개념으로 생각하는 게 좋습니다. 또한 위젯은 스크롤이나 트랜지션이 원활하지 않으므로 이 점을 충분히 감안해서 설계하여야 합니다. 요즘들어 안드로이드 사양이 점점 좋아지고는 있다고 하나, 아직까지는 위젯의 기능을 무겁게 가져가기에는 부담이 좀 있는 상황입니다.


4. 기타 고려사항은 없는지 살펴보아야 한다.
- 어떤 안드로이드 단말의 경우 위젯모드를 세로모드 뿐만 아니라 가로모드도 지원하기 때문에 가로모드에 따른 위젯을 추가적으로 개발해야 할 수 있습니다.

- 위젯 크기에 따라 종류별로 추가 셋트를 구성할 수 있습니다. 예를들면 작은 위젯, 중간 위젯, 큰 위젯의 3가지 세트를 만들어놓고 사용자에게 선택하게 하는 것이죠. 하지만 너무 많은 종류의 위젯을 지원하다보면 사용자 입장에서는 선택을 하는데 있어서 혼란을 가중시킬 우려도 있습니다. 선택해보기 전까지는 크기 외에 어떠한 정보도 알수 없으니까 말이죠.

[그림6] 안드로이드 위젯 선택 UI

- 또한 위젯 정보 동기화 이슈가 있습니다. 위젯의 정보를 몇시간마다 가져와서 보여질 것인지에 대한 고민이 필요합니다. 당연히 수시로 정보를 업데이트 하는것이 좋지만, 성능의 문제가 있으므로 수동 업데이트 버튼을 추가로 제공해야 할지를 고려해봐야 합니다.

- 음악 위젯의 경우 락스크린 UI도 고려해야 합니다. 락스크린 UI는 단말이 락이 걸려있더라도 사용할 수 있는 UI인데요, 음악의 경우 멀티태스킹이 가능하기 때문에 락 스크린 UI를 추가로 구성할수도 있습니다.

[그림7] 안드로이드 윈앰프 락스크린(우측)



글을 마치며...
적고보니 다소 일반적인 이야기가 된 것 같습니다. 하지만 기본에 충실한다면 위젯을 기획하는데도 도움이 되지 않을까 생각합니다. 때로는 정공법도 도움이 될때가 있습니다.

현재 안드로이드 위젯 가이드라인이 존재하기는 하지만, 가이드라인이 실제 기획과 디자인을 하는데 있어서 모든 부분을 커버해주지는 않습니다. 그렇기 때문에 어느 부분에 한해서는 새롭게 적용해야 하는 부분이 있을것으로 생각합니다.

또한 안드로이드 3.0(허니콤) 위젯을 제작할 때에는 퍼포먼스의 향상으로 인해 위젯 3D UI를 시도해 볼 여지가 있습니다. (본 포스팅에서는 안드로이드 3.0 위젯에 대한 문제는 논외로 합니다.)

감사합니다. 

PS. 글쓰는데 도움 주신 이재용님 감사합니다.


참고자료

노주환, 웹 패러다임을 바꾸는 위젯, 멘토르, 2008

루크 로블르스키의 터치 영역 사이즈
http://www.lukew.com/ff/entry.asp?1085

위젯의 역사와 종류
http://1370.me/694

안드로이드 위젯 가이드라인
http://developer.android.com/guide/practices/ui_guidelines/widget_design.html





팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 1 Comment 10
Ad Test...
2010.04.27 18:56

암기 프로그램, 왜 이런건 없는거야??

저는 암기를 잘 못합니다.
그래서 초등학교 때부터 시험 볼 때 마다, 죽을 맛 이었습니다.

어릴적 공부잘하는 친구집에 놀러갔다가
그 친구의 '깜지(암기의 흔적)'를 보고 깜짝 놀랐습니다.
저는 그냥 빼곡히 무작정 박박 외우기만 했는데,
제 친구는 앞글자만 따서 외우거나, 그림을 그려서 외우거나 하는 등
다양한 테크닉을 구사하고 있었습니다.
(다 큰 후에 연상기억, 위치기억 등 그런 것이 체계화 된 '기억법'으로 존재한다는 것을 알았습니다.)

여튼 오늘 하고 싶은 이야기는 '암기'에 관한 이야기 입니다.
한 평생 암기를 잘 못해 고통받은 사람이 그것을 극복하고자,
다양한 시도를 했던 경험을 나누고자 합니다.ㅎㅎ
저같은 사람을 위해 궁극의 암기용 App. 하나를 만들어보고 싶군요.^^*


반복 학습(단순 무식!)
현재 나와있는 암기 S/W들은 대부분 반복학습을 쉽게 도와줍니다.
소위 말하는 에빙하우스의 망각곡선을 근거로 무조건 반복하라는 공산당식 프로그램들 입니다.

사용자 삽입 이미지

그 근원은 당연히, 영단어장 이지요.

저는 보통 영단어를 100장정도 쓰다가 지쳐서
내다 버렸었어요.  
보통 외운건 제외시키고, 못외운것 위주로 버스안에서 계속 반복하죠.
쉬는 시간에 써야한다는 압박에 언제나 제대로 쉬지도 못합니다.
대단한 인내심과 자기제어를 요구합니다.


제 아이폰 첫 페이지를 장식하고 있는 '플래시카드 App.'
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지









아이폰 App.중에 영단어장의 경험을 훌륭하게 잘 살려주는
것들이 꽤 많이 출시되었는데요.

가장 좋은 개선점은 간단한 체크로 외운것과 아닌것의 관리가 쉽다는 것.
또한 다른 사람들의 단어장을 나도 외울 수 있다는 것(?) 정도입니다.
하지만 이것도 암기장처럼, 입력하다가 지쳐서 잘 보진 않습니다.^^*


PDA에서도 '암기S/W'는 필수 였는데요. 그때 왕 유명하던, '암기왕 프로그램'입니다.
사용자 삽입 이미지
사용자 삽입 이미지
 

그 당시에는
혁신적인 기능과
인터페이스로
뭇 암기인들의 선망의
대상이었는데,

지금 보니까
구시대의 유물같아서
좀 슬프군요.







이런 반복 학습의 최고봉은 역시 특허받은 학습법 '깜빡이'!!!!
사용자 삽입 이미지
사용자 삽입 이미지
사실 깜빡이는 안써봤습니다.

인터페이스만 봐서는....
아이폰 플래시 카드와
PDA 암기왕의 중간 정도 같은
느낌인 듯 합니다.

S/W의 독창성을 내세워,H/W까지 세트로 파는 상품성에 박수를 보냅니다.



쓰면서 외우기(손 끝으로 외운다)
특히 한자 학습에 많이 사용되죠. 깜지나, 먹지 라고 불리기도 하구요.
사용자 삽입 이미지
사용자 삽입 이미지








사실 이 암기는 단어장 보다 더한 공산당이지만...
한자나 영어 스펠링 외울때는
이보다 막강한게 별로 없죠.
손톱 빠질 때까지 줄창 쓰는겨!


진도가 너무 천천히 나가서 답답했던, 닌텐도 영어 삼매경!
사용자 삽입 이미지
사용자 삽입 이미지

스펠링에 약한
스스로를 깨닫게 해준
딕테이션(받아쓰기)를
강조한 영어삼매경.

진도가 너무
천천히 나가서
마치
깜지를 일주일에
걸쳐 쓰는 느낌이었지요.





연상 기억법 (스토리, 그림, 위치로 기억한다.)
사용자 삽입 이미지

저는
특이한 기억법들을
좋아합니다.
매번 시험때마다
기억법을 고안해내다
진짜 공부는 하나도 안했었죠.

특히 가장 좋은 것은,
위치 기억입니다.

왼쪽 화면 컨텐트는
(50 English)
각 그림 위치별로 영어 문장을
대입하여 외우도록 하게 되어 있습니다.
스토리도 있지요!

이런 방법으로
영어 50문장을
단숨에 외워 본 경험이 있지요.
WOW!





이런 방법은 사이버 강좌 등에 많이 사용되고 있는데요.

사용자 삽입 이미지

하지만,
이런게 컨텐트 제공업체가
일방적으로 내용을 공급하는
것이고
(왼쪽은 정철 사이버)

사용자가
직접 제작해서 만드는
WIZWIG
방식의 연상기억법
프로그램은 아직
본 적이 없습니다.







요즘도 외울일이 꽤 많은데,
시중에 나오는 건 단순 반복 암기 프로그램 뿐이라... 입맛 만 다시고 있습니다.

좀 더 창조적이고 재미있는 방식의 암기 프로그램이
있으면 추천해 주세용!!!







팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2010.04.23 10:54

낙서에 가장 적합한 디바이스는?


저는 낙서를 좋아합니다.
사실 미대를 간 이유도, UI라는 직업을 택하는 데도, 낙서의 영향이 컷습니다.
낙서의 정의를 제 맘대로 '생각을 눈에 보이게 대충 그리는 것'이라 칭하고 싶습니다.

이런 자신의 생각을 대충 그릴려면, 도구가 필요합니다.
제가 오늘 하고 싶은 이야기는 '생각을 그리는 도구'에 대한 이야기 입니다.
아날로그의 그리는 경험을 디지털로 옮겨오는 과정에서 생기는 문제와 가능성을 이야기하고자 합니다.


첫번째로, 제가 낙서에 애용하는 도구는 '포스트 잇' 입니다.

사용자 삽입 이미지
사용자 삽입 이미지
포스트잇의 장단점은
다들 써보셨기에,
따로 말할 필요가 없겠지요.
ㅋㅋ

저는 포스트잇을 지갑에 달고 다닐 정도로
수시로 낙서에 애용합니다.


이런 포스트 잇을 디지털화 한 제품이 '민트패드' 였는데요.
포스트 잇을 컨셉으로 잡은 것 자체가 정말 훌륭하고 매력적이라고 생각했습니다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지








뭐 제품 자체의 완성도는
둘째치더라도..

일단 휘발성인
포스트잇을
디지털환경으로 바뀌며
쉽게 보관하고
관리/공유
할 수 있다는데에
장점이 있겠습니다.



하지만 디지털화 되면서 아쉬운 점은..
포스트잇의 놀라운 확장성이 없어졌다는 점이지요.ㅠㅠ
이런 확장성으로

사용자 삽입 이미지

생각을 시간에 관계없이
계속해서 축적-발전 시키고
한눈에 볼 수 있게 만들거나,

여러사람이 동시에
생각을 꺼내놓기도 하고,













사용자 삽입 이미지

부분적으로 수정해가며,
관점을 가지고 정리하며
체계화 하는 작업들이 가능한데...

뭐 하지만 이렇게
저처럼 포스트잇을
이상하게 사용하는 사람이 많은 것은
아니니까..패스~














두번째로, 제가 낙서에 가장 애용하는 도구는 노트지요.
사용자 삽입 이미지

이면지에 낙서하는
것만큼 즐거운 경험은
없지요.

마음대로
손이가는 대로 적다가
맘에 안들면
버리면 그만이니까.

비용은 제로에
재미는 최대!
사용자 삽입 이미지

다이어리나
노트에도 낙서를
자주 합니다.

낙서를
축적해서 하다보면
몰랐던
자신만의 관점을
발견하기도 합니다.

호오~









이런 노트와 음성녹음을 합쳐 디지털화 한 제품이
'라이브스크라이브' 였는데요.

사용자 삽입 이미지
디지털 펜으로
녹음이 되고,

자신이 기록한 부분에 맞춰
녹음된 음성을
다시 되돌려 들을 수 있죠.

음성-텍스트의 싱크라는
개념자체는 엄청
매력적이고 훌륭합니다.






사용자 삽입 이미지
 
하지만 실제로 써보니

노트값이 너무 비쌌고,
ㅠㅠ

저는 노트 전체 구석구석을
이리저리 왔다갔다
하면서 기록하는 편인데,

이것은 노트 왼쪽 끝부터
오른쪽 아래까지
순서대로 기록해야 하는
제약이..
저를 숨막히게 하더군요.

공부할 때는 좋은 것 같습니다.
낙서할 때는 별로...


타블렛 피씨를 사용해도 노트와 유사한 경험을 할 수 있지요.
사용자 삽입 이미지



요즘엔 아이패드가 인기던데.

저는 대학교 때에(4-5년전)에
타블렛 피씨로
낙서와 필기를 해볼까 해서
샀었구요.

아래와 같은
방식으로 필기 했었습니다.

사용자 삽입 이미지




디지털 텍스트 입력과
아날로그를
오가며
자유롭게 사용할 수 있다는게
장점이라면 장점이구요.

단지 안타까운 점은

장시간 사용시
손이 뜨거워져서
겨울엔 좋지만,
여름엔 낙서하다
쪄죽었던 기억이...

또한
필기 해놓은 것을
노트처럼
앞 장 뒷장 비교해가며
보기가 어렵고,
한번에 한장씩 모니터로
봐야
하는 불편함이 있습니다.
매번 출력하기도 짜증나죠.


그 이외에도 워드 프로그램이나 마인드 맵 프로그램이 있을 수 있겠는데,
사실 자유로운 생각을 적기에는
너무 사무적이고, 텍스트 중심적이지요.


목적에 따라 다르겠지만,
아직까지 최고의 낙서 솔루션은 아무래도 종이와 펜인 듯 싶습니다.
다음은 IDEO가 아니라 adaptivepath에서  직원들이 사용하는 스케치 KIT예요.
PXD에서도 전수석님이 도입하셨었는데, 저만 즐겁게 사용한듯..ㅋㅋ
사용자 삽입 이미지

 




































사용방법은 나중에 제가 번역해서 한번 올려볼께요~
http://www.adaptivepath.com/ideas/essays/archives/001072.php
궁금하신 분은 원문을 먼저 보시고요~^^*

감사합니다.

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 7
Ad Test...
2010.04.09 19:32

“퍼소나가 유니버설 디자인 제품에서도 활용 될 수 있을까요?”

아래 내용은 피엑스디 사내 메일 토론을 정리한 것입니다.

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

“퍼소나가 유니버설 디자인 제품에서도 활용 될 수 있을까요?”

사용자 삽입 이미지

아래 '편리해진 KTX- 장애인에게는 도리어 불편' 이라는 기사를 접하고, 궁금한 점이 생겼습니다.  

‘편리해진’ KTX-Ⅱ 장애인에겐 더 불편 동아일보, 2010

대부분(80%) 사용자에게 편안함을 주기 위해 의자 앞뒤 좌석 간격을 늘리자.라고 설계자는 판단한 것 같습니다. 그러다 보니 5% 사용자는 이용 할 수 없는 기차 복도 크기가 나왔습니다.
'80% 사용자를 만족시키기 만해도 잘한 것이다.'라는 주장이 무색해 보입니다.
기획자로서 최소한의 책임의식(그냥 알아서 잘 배려해라!)을 강조해주면 해결 될 문제 일까요?
이런 문제는 이미 유저 모델링에서는 드러나서 많이 공론화된 문제 인가요?
궁금하네요?


사용자 삽입 이미지
“도구는 가치 중립적이니까요. 결국 결정은 기획자가 하는 겁니다.”
장애인-비장애인 구도로 보지말고, 그냥 다수 vs 소수라고 봐도 되겠죠?
누구든지 소수가 될 수 있으니까 더 현실적으로 느껴질겁니다.
그리고 다수-소수 문제로 보면 그야말로 반복, 또 반복되는 문제라고 봐야겠죠...
제한된 자원 내에서 효율을 추구한다면 '다수'만을 배려하는 것이 가장 좋겠습니다.
다만, 시장을 확대하기 위해선 '소수'도 배려해 주면 좋은데 이 때 퍼소나를 사용하면 좋은 점은,

"누가 다수인지, 누가 소수인지, 그들이 어떤 특성을 갖는지 매우 명확하게 아는 상태에서" 둘 사이의 타협을 시도한다는 점입니다.
막연히 모두가 좋자는 것이 아니라, 전략적 타협을 할 수 있다는 거죠.

제한된 자원을 결국 어떻게 나눌 것인가는 여러 가지 상황에 의해 좌우됩니다.
반드시 '효율'만이 요소는 아니라는 거죠. 위에서 언급했듯이, 시장 확대라든지,
기업(상품)의 포지셔닝 때문에라든지, 현재의 경쟁 구도라든지, 자기들이 잘 할 수 있는 것이라든지...
그 중 한 가지가 '도덕적 만족감' 혹은 '사회적 책무를 다 하는 듯한 기업 이미지' 등이 있을 수 있겠죠.
휠체어용 경사로가 생기면 계단이 좁아져서 대부분의 사람들은 불편합니다.
대신 노약자들은 편하겠죠. 누구나 노약자 가족이 있고, 또 스스로 노약자였거나, 노약자가 됩니다.
따라서 효율이 떨어지고, 자기가 불편해도 대부분의 사람들은 비효율적인 경사로를 보면서 심리적 만족감을 얻습니다.
그런 부분이 중요합니다!!! 만약 매우 소수의 사람들이 복도를 지나가게 하기 위해 자리를 좁게 만들어야 한다면, 어떻게 대다수의 사람들이 좁은 좌석 대신 심리적 만족감을 얻을 수 있을까요? 의자에 앉으면 앞에 이렇게 써 있으면 어떨까요?

"좁으세요? 바퀴로 복도를 지나가야만 하는 사람들을 위해 자리를 좁혔습니다. 고맙습니다!"
아니면, 좀 암묵적으로 바닥에 휠체어 바퀴 자국을 그려 놓는 건 어떨까요?

복도 바닥을 보면 왜 복도가 그 정도 폭이 되어야 하는지 눈치챌 수 있도록 말이죠.
제한된 자원 내에서 퍼소나를 사용하면, 주먹구구 결정이 아니라 전략적 타협을 할 수 있게 됩니다.
퍼소나가 소수 배려 제품에서 잘 활용될 수 있습니다. 하지만 당연히.... 퍼소나를 쓴다고 해서 무조건 소수가 배려가 되는 건 아닙니다.
도구는 가치 중립적이니까요. 결국 결정은 기획자가 하는 겁니다.



사용자 삽입 이미지
퍼소나를 결정하고 해결할 문제를 선택하는 게 아니라
해결해야 할 문제를 선택하기 위해 퍼소나를 사용하는 것이지요.”

퍼소나는 사람들이 서로 다른 문제를 가질 수 있다는 것을 인정하고 디자인을 하겠다는 방법이지그것이 꼭 프라이머리 외에는 다른 사람들의 문제를 배제하겠다는 것은 아닙니다.
어떤 것이 정말 중요한 것인지 의사결정할때 서로 다른 facet 값들을 함께 비교하기는 애매하기 때문에
decision tree 같은 것을 만들어서 확률과 가중치의 곱을 합한 하나의 기대 값을 계산해서 비교하게 됩니다.
공식으로 만들어 사용할 수도 있고요. 공식이 얼마나 의미가 있는지는 뭐 다음문제지만요.

http://en.wikipedia.org/wiki/Decision_tree

기능의  우선순위를 정할때 많이 일반화하면 얼마나 자주 사용하는가 와 중요도를 가지고 결정을 하는데
how many x how often x how critical 같은 값을 정할 때 critical factor의 가중치를 크게하면
다수의 요구사항만이 아니라 소수의 크리티컬한 문제들도 고려할 수 있게 됩니다.

퍼소나를 결정하고 해결할 문제를 선택하는 게 아니라
해결해야 할 문제를 선택하기 위해 퍼소나를 사용하는 것이지요.

problem driven.
TRIZ

이런 물리적인 모순 상황에서 무조건 다수가 소수를 배려하여 조금 손해를 보고 대신 대안의 가치를 준다라는 간단한 해결만 있을 것 같지는 않습니다.
TRIZ에서 이런 물리적인 모순은 분리를 통해 좀 더 좋은 해결을 찾을 수 있다는 것을 보여주거든요.
공간의 분리를 적용하면 우선 떠오르는 게 지하철처럼 출입구 쪽에 특별석을 지정해서 제공할 수 있을 테고요
비즈니스 클래스같은 전용칸을 별도 운영해서 업그레이드 해줄 수도 있겠고요.
저도 중간에 자리를 주면 귀찮은데, 휠체어를 타고 통로를 꼭 지나다녀야 할 필요를 줄여주면 서로 행복할 수 있을 것 같아요.


사용자 삽입 이미지

“그런데 무슨 방법론을 쓰더라도, 다수의 희생 없이는 불가능합니다.
'제한된 자원'이라는 상황이니까요.”

트리즈를 이용하는 건 좋은 생각이네요. 한 선임이 트리즈에 좀 더 많은 관심을 갖고 논의를 촉발시켜 주면 좋을 것 같습니다.
그런데 무슨 방법론을 쓰더라도, 다수의 희생 없이는 불가능합니다. '제한된 자원'이라는 상황이니까요.
예를 들어 입구 근처의 특별석 같은 아이디어도 매우 참신한데, 역시 다수의 희생이 필요하죠.
그 자리는 예약의 마지막 순간까지 일반인들이 앉지 못 하고 비워 두어야 할 테니까요.
KTX 휠체어 이용자 비율이 얼마나 되는지 알 수 없지만 어쨌든 일정 비율의 의자를 비워둔다는 건 희생이 될 수 밖에요.
비워두지 않고 일반인에게 배정한다고 하더라도 다른 의자보다 더 좁은 의자에 앉아야만 하는 사람은 불만이 생길 것이고요.
또 자리 선택 프로그램이나 창구 좌석 예매 절차 또한 복잡하게 됩니다. "이런 자리인데 앉으시겠어요?"라고 꼭 물어봐야만 하니까요. 특별석이 이런데 특별칸 같은 경우는 말할 필요도 없겠죠.
그렇다면 시간에 의한 분리는 어떨까요?
좌석 자체의 폭이 늘었다 줄었다 하는 경우 말이죠. 평소에는 폭이 넓었다가 휠체어가 지나갈 때는 줄어드는 의자. 가능하겠죠? 하지만 마찬가지로 대다수의 희생에 근거합니다. 

일부 좌석만 그렇게 만들면 위의 특별석 문제가 발생하고, 전체 좌석을 그렇게 만든다면 객차 중량 증가 및 제작 비용 증가로 인해 대다수의 요금 상승으로 이어지겠죠.(장애인에게 특별히 비싼 요금을 매기지 않는 한)

어떤 방법으로 대처해도, 결국 한 가지로 제공하는 것 보단 비용이 들어간다는 거죠.
두 가지를 지원하면서 한 가지 지원보다 비용이 줄거나, 최소한 같은 경우라는 것이 있을 수 있을까요?

제 생각엔 힘들어보이는데...


사용자 삽입 이미지

“좁은 통로를 해결하려는 게 아니라
다녀야 할 필요를 줄인다로 문제를 정의하는 데서 출발 한 것이지요.”

휠체어가 다니기 어려운 좁은 통로가 문제인데 해결을 통로를 넓히는 게 아니라
통로를 다녀야 할 필요를 줄여야 한다로 문제를 정의하는 데서 출발을 하려고 한 것이지요.
problem driven goal directed design에서 얘기한 증상에서 좀더 근본적인 문제를 찾으려 한것입니다.
요즘 복도식 아파트는 안 짓잖아요.

사용자 삽입 이미지
예전에 수업으로 서울대에서 장애인 특례입학 정원을 높이는것에 대한 찬반토론이 있었는데 다들 서울대에서 우선 모범이 되어 특례 입학을 높여야 한다고 하더라고요.
전 미친짓이라고 생각했지요. 학교가 산꼭대기에 있어서 나도 다니기 힘들어 죽겠는데 물리적으로 최악인 열악한 환경에서 무슨 장애인을 위한 배려를 한다는 건지 이해가 안되더라고요.
강의동이 모두 언덕길에 있어서 같이 수업을 듣던 장애학생은  혼자서 이동을 하지 못하고 매 수업마다 입구에서 지원차량을 기다려야했는데 배려가 아니라 몹쓸짓을 하는것 같았어요.
학부수업의 질은 별로 차이가 나지 않으니까 평지에 있는 연대같은데서 스스로의 힘으로 수업을 들을수 있게 학점 교환 프로그램 같은걸 운영하는게 정말로 위하는게 아닐까 싶었거든요.
특별석이나 특별칸은 장애인 전용이 아니라 프리미엄석으로 누구든 돈을 더 많이 내면 얻을 수 있도록 하는거에요.
아마 현재도 운영되고 있을거에요. 단지 장애인에게는 무료 업그레이드 혜택을 주는거죠.
일등석이랑 비즈니스석은 항상 빈자리가 있잖아요. 돈으로 차별하면 공평해요.


사용자 삽입 이미지

“우리가 UX전문가로서 몇 가지 문제만 확인하고 바로 해법을 '내려주려' 하지말고,
사용자의 눈높이가 되어 진정으로 사용자를 이해하는 것이 중요합니다.”

일단 비즈니스용도의 넓은 좌석과 장애인용도의 넓은 좌석은 다르게 생겨야 할 것 같으므로 패스하죠.
비즈니스 용도의 좌석을 만드는 목적과 장애인을 위한 좌석의 목적도 다를 것 같구요.
아래 오고가는 메일 내용에서 '소수 장애인을 위한 배려'로서의 공공디자인에서 퍼소나라는 방법이 유효한 것인가 라는 질문이 핵심인 것인데요, 퍼소나를 만드는 과정을 '데이터를 공식에 대입하여 자동으로 연산되어 나오는 과정'으로 생각한다면 80%의 만족이라는 부분에 대해 오해가 생길 것 같습니다.
단순한 사용자 조사과정 외에 다양한 이슈들을 리서치 하는 과정에서

'중요한 이슈라면' 발견되어야 하고 고려되어야 할 것인데,
이것을 어떻게 하면 안 빠뜨리고 고려할 수 있는가?

어느 정도로 '적절히' 고려해야 하는가..라는 가치판단이 필요한 것 같습니다.
이 대목이 디자이너의 역량에 해당하는 부분일 수 있고, 사회적인 '상식'의 선에서, 혹은 사회가 나아가야 할 지향점의 가치판단 하에서 고려되어야 한다는 것이죠.
현재로서는 이 부분을 어떻게 하면 잘 할 수 있는지에 대해 언급된 방법론은 없는 것 같습니다.
체크리스트 정도로는 가능할 것 같은데요.
체크리스트 수준이라도 좀더 구체화해보면 도움이 될 것 같습니다. 퍼소나 체크리스트라는 것이 대체로 다소 모호하기도 하고 판단하는 사람의 기준에 따라 달라지기도 하는 취약점이 있는것도 사실입니다.
장애인석과 비즈니스 석은 목적 자체가 다르기 때문에 어느 하나로 나머지를 단순히 커버할 수 있을 것 같지는 않습니다.
단순히 제품이나 의자 간격만이 아니라 목적을 이루기 위한 토털 솔루션 (서비스까지 고려된)이 중요합니다.

사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지
사용자 삽입 이미지

비행기에서는 통로가 좁기 때문에 특별히 제작된 휠체어를 제공합니다. 그것도 공항에서 이용하는 것과 기내에서 이용하는 것이 다릅니다. 바꿔 탈 수 있도록 서비스를 제공하고 있고, 장애인의 휠체어도 보관해 줍니다.

아마 좌석도 휠체어를 고정하여 비행기 좌석 사이즈가 되도록 고안된 것 같습니다. 고정시키는 것도 스튜어디스가 도와줍니다. KTX에서는 어떻게 해야할까요?
부산까지 2시간 반이면 되는 거리에서 비행기처럼 특별히 제작된 휠체어가 필요할까요?
물론 경제성도 고려해야 하지만 사회적 비용으로서 복지예산이 팍팍 지원된다 하더라도 말이죠.

아주 길지 않은 시간이라면 안락한 의자보다는 휠체어 자체가 더 나을지도 모릅니다.
아래 KTX의 예는 좀 성의없어 보이지만 쓸 수 없는 상태보다는 낫죠.
여기서 쓸 수 없는 상태란 비즈니스석에 힘들게 앉아도 휠체어를 보관해줄 사람이나 서비스가 없다거나, 화장실 한번 갈 때에도 나의 휠체어를 갖다가 옮겨 앉게 도와주고 하는 서비스 일체를 말합니다. 또한 장애인이 이용할 화장실도 일반인의 화장실과는 다르겠죠.
우리가 UX전문가로서 몇 가지 문제만 확인하고 바로 해법을 '내려주려' 하지말고, 사용자의 눈높이가 되어 진정으로 사용자를 이해하는 것이 중요합니다.


사용자 삽입 이미지

“기획자의 역량에 따라 '체크리스트'를 챙기는 것 이외에
별다른 방법은 없는 것 같네요.”

기획자의 입장에서, 그들이 무언가를 기획할 때 판단기준을 '퍼소나' 라는 방법론을 써서 세우면 확실히 [상대적 소수]는 배려할 수 있을지 몰라도, [완전한 소수자]에 대해서는 놓치고 마는 우를 범할 수 있을 것 같습니다.
뭐 비용의 문제로서 다수/소수 문제로 치부해 버릴 수도 있지만, 상당부분 기획 초기단계의 배려만으로 추가비용 없이 해결 할 수 있는 부분도 있습니다. ('왼손잡이를 위한 가위' 등은 오른손/왼손 잡이 다쓸 수 있고, 제작공정의 추가비용도 없습니다.)

특히 UI같은 인터페이스 디자인은 더욱 추가비용 없이, 기획자의 역량에 따라 사용자의 폭이 달라질 수도 있을 것이라고 봅니다.고민해봐도 수석님이 언급하셨던 기획자의 역량에 따라 '체크리스트'를 챙기는 것 이외에 별다른 방법은 없는 것 같네요. 그래서 UD분야 사람들이 자꾸 PPP같은 체크리스트를 만드나 봅니다.
매번 새로운 도메인을 기획할때 최소한의 소양을 갖출 필요가 있을 것 같습니다.

세탁기에서 배려해야 할 최소한의 체크리스트.
네비게이션에서 배려해야 할 최소한의 체크리스트. 등
기존에 이런 것이 없다면, 프로젝트 틈틈이 만들어가는 것도 재미있을 것 같네요.

사용자 삽입 이미지



사용자 삽입 이미지
“교훈: 신문기사 하나 읽고 사용자의 문제를 이해할 수 없다.”

국토해양부에서 교통시설 디자인 할때는 장애인 단체나 관련 전문가 의견을 듣도록 권고하고 있는데
그런 프로토콜을 안따른게 문제인것 같아요.
UD만이 아니라도 새로운 관점을 볼 수 있으니까 보고서 한번 읽어 보면 좋겠네요. 보고서에 교통약자라는 표현을 쓰는데 괜찮아보이네요.

그리고, 위키피디아의 장애인 용어에 관한 부분도 참고할만 합니다. 

한편 영어권에서는 전통적으로 Disabled 디세이블드라는 용어를 사용해 왔다.
한때 Handicapped핸디캡트가 더욱 정치적으로 올바른 용어라는 주장이 있었으나, 장애우와 비슷한 이유로 쓰이지 않게 되었다. 영어권의 장애인들은 Handicapped라는 용어를 모욕으로 느끼기도 한다. 그들은 다리에 장애가 있는 경우 휠체어를 탐으로써 보정할 수 있기 때문에 handicapped가 아니라고 생각한다.
일반적으로 영어권에서 장애인을 뜻하는 용어로는 Disability 디세이블리티 또는 Disabled를 쓰며, 이 표현이 수식할 사람(Person)이 앞에 붙는 것이 적절한 표현으로 간주된다. 이를테면 a Person with Disability가 있다.  http://ko.wikipedia.org/wiki/장애인

배려가 필요한 마이너 퍼소나를 위한 heuristics 같은건 UI 전문가가 아니라 진짜 전문가인 실제 사용자가 평가를 해봐야 알 수 있게 되는거 아닐까요?

PPP평가라는 것도 그렇게 만들어진 거겠죠?
결국 아무리 완벽하게 준비를 한다고 해도 완벽한 결과를 기대하는 것은 무리인 것같고
리스크를 줄이기 위해서 여러 단계의 평가과정 자체가 프로토콜이 되어야 할 것 같아요.

2007년 기사("휠체어장애인은 단체로 기차 못 탑니까?" 평화뉴스)인데요. ktx는 원래부터 특실 칸에 별도 장애인 공간을 마련하고 있었네요. 기사는 전용공간이 너무 부족하다는 것을 지적하고 있습니다. 장애인 단체 10명이 함께 여행하고 싶었지만, 한 기차에 2명-4명 밖에 탈 수 없다는 겁니다.
일반석의 통로가 좁은 건 문제가 아니었습니다. 원래 휠체어로 통로를 이용하지 않았으니까요.
교훈: 신문기사 하나 읽고 사용자의 문제를 이해할 수 없다.

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

결론: 이메일 토론은 별 합의점 없이 각자 생각에 그치는 것으로 끝났습니다만, 구성원들이 공공 교통과 휠체어 장애인에 대해 깊이 생각해 보는 계기가 되었습니다.

아래 내용은 이후 추가된 참고 링크들입니다.
휠체어 장애인과 함께 열차여행, '생고생'이네 (2009)
휠체어 장애인은 새마을호 이용 못한다 (2010)
코레일, 신형 장애인 휠체어 승강리프트 오픈 (2010)

[참고##사회공공디자인##]


팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 3
Ad Test...
2010.03.20 21:30

Workflow 협업하여 함께 그리기! 3-day!

사용자 삽입 이미지
                                            함 가보는거야!! 그까이꺼!

<저는 뭐 별로 아는 것도 없는 사람이라, 저와 한배를 탄 동료들과의 즐거운 경험을 나누고자 합니다.^^*>

팀으로 작업을 하다보면,손발이 맞을 때까지 걸리는 시간이,
때로는 실제 작업시간보다 더 걸리는 경우도 있지요^^*

특히 일관된 컨셉의 Workflow를 여러명이 그리는 것은,
결코 쉬운일이 아니었습니다. 그래도 다른 분들의 시행착오를 좀 줄이시라고
모바일 Application을 세명이서 그렸던 협업 사례를 기록으로 남겨 봅니다.

다음 프로세스는
Goodwill / 금룡 / UXdragon
요 세명이서 여러번의 시행착오 끝에 얻어낸 그나마 썩 꽤 효율적이라고 여겨지는
Workflow 협업 방식입니다. 다른 사람들은 어떻게 하나 궁금하네..ㅎㅎ
 
 
Day 1. index부터 만들어라!
하나의 모바일 App.을 그리는 데 초반부터 효율적으로 착착 나눠서 일하기를 기대하는 것은 어렵지요.
일단 모든 팀원이 하나의 'Goal'이 머리에 그려질때까지 소통이 필요합니다.
Day 1은 모든 팀원들이 한 머리를 가지게되는 과정입니다.
1. 기존 자료를 리서치 해본다. (1시간)
2. 각자 자신이 상상하는 App을 포스트잇으로 대충 쓱쓱 그려본다. (3시간)
3. 서로 싸우며 현재 가장 좋아보이는 시안을 도출한다 (1시간)
4. Workflow 기획서 작업에 들어가기 전에 갖춰야할 전체 index를 최대한 구체적으로 세운다.(2시간)
 
기획서 index를 만드는 이유는 세명의 머릿속에 모두 같은 큰그림을 그리기 위해서 입니다.
완벽한 index에 시간을 쏟는 것보다는, 전체 속에서 자신이 잘 할 것 같은 영역을 찾아가는 게 더 중요합니다.
index 초안이 완성되면, 각자 적절히(하고싶어하는 순으로) 나눠, 페이지를 일단 고속으로 채웁니다.



Day 2. 하나의 Form이 손에 익기까지!
모든 일에는 시행착오가 있으니, 차라리 시행착오를 적절하게 활용하는게 좋은 것 같습니다.
개략적인 Form 안에서 Key Rule/Key Flow/Key Page를 일단 토하내듯 쏟아놓고 맞춰가는게 중요합니다.
Day 2는 모든 팀원이 한 손을 가지게 되는 과정입니다.

1.전체 index 초안에 적합한 기존의 Form을 도입하여 일단 각자 고속으로 채웁니다.(4시간)
2.마구 대충 채워진 기획서를 가지고 서로 논박을 하며 보완할 점을 찾습니다.(2시간)
3.동시에 Form의 문제점을 찾아 디바이스와 App.의 특성을 잘 녹여내기 위한 논의도 필요합니다.(1시간)

모든 인원이 Form의 한계와 활용법을 충분히 알고, App.의 컨셉을 잘 이해하면 게임은 끝입니다.



Day 3. 지금까지 참은 당신, 마음껏 그려라!
연필도 쥐고, 무슨 그림을 그려야 할 줄도 아는데, 뭐가 문제입니까.
각자 자신의 파트를 하루종일 그립니다. 이제는 각자 뛰어도 한 사람처럼 움직입니다.
그리고 퇴근 전 서로 모여 각자의 부분에 대해 Cross-checking 합니다.
마지막으로 해당 App. 최종 책임자가 전체 기획서를 정리합니다.


참 쉽죠잉?!!

항상 중요한 것은 즐겁게 일하는 것인거 같습니다.
좋아하는 일은 아무리 하지 말라 그래도 하게 되니까요잉~ㅋㅋ

위에는 제가 경험했던 Workflow 협업 방식만 언급했지만,
사용자조사 협업방식, 전략도출 협업 방식도 좀 더 고민하고 다뤄 갈 수 있었으면 좋겠네요.^^*

미흡한 저의 경험을 들어주셔서 감사합니다!

[참고##프로젝트 방법##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 2
Ad Test...
2010.03.20 11:09

좋은 네비게이션 레이블(lable)의 조건



UI 기획을 할때 레이블링하는것 만큼이나 어려운 일은 없더군요. 책을 찾아보다가 Designing web navigation 에서 좋은 네비게이션 레이블의 조건에 대해서 기술하고 있는 것을 발견했습니다. 그중 '네비게이션 레이블링 챕터' 를 정리해 보았습니다. 네비게이션용 레이블링 뿐 아니라, 용어 레이블링 할때도 적용할 수 있을 수 있을 것 같습니다. 또한 웹사이트 기획 뿐 아니라 다른 디지털 디바이스들에도 적용할 수 있을 것 같습니다.



A. 사용자 언어로 말하기
1. 회사 전문 용어를 쓰지 않는다.
회사 전문 용어는 너무 쉽게 웹사이트에 들어가 있습니다. 이러한 전문용어는 사용자에게 도움이 되기보다는 혼란스럽게 합니다. 

2. 기술 용어를 쓰지 않는다.
대부분 방문자들은 사이트를 만든 사람만큼 웹 사이트에 대해 잘 알지 못합니다. 플러그인이 무엇인지. 보안 서버가 무엇을 의미하는지 사용자들은 궁금할까요? 사이트 타겟 방문자들의 객관적 지식수준을 고려한 용어를 사용하여야 겠습니다.

3. 너무 똑똑하거나 재미있는 용어를 쓰지 않는다.
일반적으로 너무 똑똑하고 영리하게 쓰인 레이블은 의도적으로 동작하지 않습니다. 사이트를 디자인하는 동안 재치 있는 단어들을 만드는 일은 재미있을지 몰라도, 나중에 사람들이 이러한 단어를 보고 네비게이션하려고 애써야 하는 상황은 전혀 재미있지 않습니다.

4. 약자를 쓰지 않는다.
약자는 공간을 절약하지만 사람들이 올바른 단어를 빠르게 훑어보는 것을 방해하기도 합니다. 심지어 어떤 방문자들은 특정 약자는 전혀 이해하지 못합니다. 모든 사람들이 FAQ, PDF, RSS의 의미를 알고 있는 것이 아닙니다.

5. 적절한 보이스톤을 사용한다.
일반적으로 은행 사이트의 라벨은 10대 음악 사이트와는 다른 톤으로 쓰입니다. 전자는 공식적이고 사무적이며, 후자는 젊고 모던하지요. 특정 타겟 청중들이 기대하는 적절한 레이블의 톤을 이해하는 것이 중요합니다.


B. 설명적인 레이블
레이블을 될 수 있는 한 설명적으로 만들고자 노력해야 합니다.
레이블이 나타내는 콘텐츠에 대한 실마리를 제공해야 합니다.
넓고 모호한 레이블을 써야 한다면, 어떤 방법으로든 뜻을 한정하고자 노력해야 합니다.


C. 상호 배타적인 레이블
레이블은 메뉴에서 그룹으로 나타나는 경우가 많습니다. 한 레이블의 의미는 연속해 있는 다른 레이블의 해석에 영향을 줄 수 있기 때문에, 가능한한 레이블을 구분해야 합니다.


D. 명확한 초점을 나타내는 레이블
초점이 맞추어진 레이블은 보다 예측하기 쉬우며 네비게이션을 하는 동안 사용자들의 자신감을 증가시킵니다. (예를 들어 고양이, 강아지, 햄스터에 대한 카테고리를 동물이 아닌 애완동물이라고 씁니다. 반면에 고양이과  & 개과 는 너무 상세해서 햄스터가 들어갈 수 없습니다.)


E. 일관된 레이블
일관된 레이블은 모호성을 없앨 수 있습니다.

1. 정밀도
정밀도는 상세 내용이나 주제의 상대적인 폭을 의미합니다. 사이트 구조에서 동일한 레벨에 있는 네비게이션 옵션들은 동일한 콘텐츠의 폭이 담겨있습니다.

2. 구문론
네비게이션의 레이블은 모두가 비슷한 문법적 구조로 되어 있어야 합니다. 언어의 동일한 부분을 사용하도록 노력해야 합니다.

3. 표현
서체나 크기, 스타일등을 일관성있게 사용하여 통일감을 주는 것이 중요합니다.

4. 사용
여러 곳에서 동일한 옵션을 지칭할 때 동일한 레이블을 사용합니다. 이러한 일관성은 인쇄와 같은 다른 미디어 채널에도 마찬가지로 적용되어야 합니다.


F. 레이블의 길이
레이블이 길면 사람들이 찾고 있는 계기가 되는 단서가 포함되고 있을 가능성이 높습니다. 하지만 레이블의 길이는 제한을 두어야 합니다. 스풀은 13단어 이상의 링크는 성능이 형편없으며, 사람들이 한 번에 이해할 수 있는 양이 정해져 있다고 하였습니다. 궁극적으로 레이블에 몇개의 단어가 필요한가에 대해서는 엄격하게 정해진 규칙이 없습니다. 하지만 화면 영역을 더 많이 사용해서라도 명확하고 구체적으로 표현하는 편이 낫습니다. 명확하게 표현하기 위한 한 가지 테크닉은 짧은 레이블을 사용하되 옆에 설명문을 붙이는 방법이 있습니다.



팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 0 Comment 0
Ad Test...
2010.03.19 15:51

멘탈모델-체계적인 사용자 조사계획 수립하기

Mental Models by 인디 영

pxd에서 주로 수행하고 있는 사용자 리서치에 기반한 디자인 과정에 매우 seamless(!)하게 적용될 수 있는, 이미 우리가 하고 있다고 할 수도 있지만 그보다는 좀 더 디테일하게 과정이 분절된 방법이라고 할 수 있습니다. 아직 제가 책을 읽는 과정이어서 차차로 연재해야 할 것 같습니다.

여기서 말하는 멘탈 모델이란 기존에 우리가 알고 있던 정의(사용자가 이해하고 있는 '시스템의 구조적인 작동방식'에 대한 추상화된 인지적 모델 - 현재 제가 이해하고 있는 정의입니다 ^^;)과는 좀 차이가 있습니다. 한마디로 특정 주제(제품? 서비스?)에 대한 사용자 행동의 친화도(affinity diagram-연관성있는 것끼리 그룹핑한 구조)를 멘탈 모델이라 정의하고 있습니다. 이렇게만 보면 좀 애매하죠?

pxd에서도 유저 리서치 데이터를 정리하고 디자인 아이디어를 얻고 전략을 수립하는 방법으로써 이 연관성 도표(affinity diagram)라는 것을 contextual design방법론의 일부로서 적극 활용하고 있었는데요, '멘탈모델'에서도 크게 보면 이와 다르진 않은 것 같습니다. 다만 정리하는 방법이 contextual 방법론에서 말하는 것과 조금 다르고 그 활용방법이 좀 더 상세하게 명시된 것 같습니다.

재미있는 것은 멘탈모델이라는 것을 프로젝트 초기부터 타겟 사용자에 대한 하나의 '가설'로서 만들기 시작하는 것인데, 이 멘탈모델 초안으로부터 사용자 조사 범위나 리크루팅 방법을 결정한다는 것입니다. 그간 contextual inquiry를 위한 리크루팅 방법이나 persona에서 사용자 인터뷰 전에 파악하고 있어야 하는 'focus'를 좀 더 체계적이고 분절된 형태의 과정을 통하여, 그리고 '협의'에 의하여 도출한다는 것이 시사점입니다.

간략하게 요약한다면 본격적인 사용자 조사 이전에 프로젝트 참여자들이 그간 확보한 리서치 데이터를 기초로 하여, 그리고 자신이 알고 있는 범위에서 사용자의 목소리로 사용자의 행동을 나열하고 이것을 통해 연관성 도표를 먼저 만드는 것입니다.

다음의 정리는 이 책에서 이야기하는 멘탈모델을 만들기 위한 앞부분 즉, 사용자 조사 이전단계까지를 정리한 것입니다.


1. 행동기반 사용자 그룹 분류

1-1.각각의 행동을 나열
브레인스토밍을 통해 나열합니다. 한두시간 정도를 투자하여 150~200개정도가 될 때까지 하라는군요.
중복되는 행동들을 모아서 대표적인 행동으로 정리하여 갯수를 줄입니다. (70개정도?)

1-2.행동을 분류하기
연관성에 따라 행동들을 분류합니다.
그리고 분류된 행동들에 따른 행위주체를 떠올려 표시합니다.
행동을 세로축으로 나열하고, 행위주체를 가로축으로 나열하여 행위주체와 행동이 매칭되는 지점을 표시합니다.
표시된 것을 바탕으로 그룹을 추출하고 이 그룹에 적절한 이름을 붙여줍니다. (얼핏 persona의 critical characteristics 패턴 매핑과 유사합니다)


1-3.분류된 그룹에 이름 붙이기
추출된 그룹을 가지고 지속적으로 논의하면서 행동의 차이와 특성에 따른 그룹의 이름을 붙여봅니다.
각 그룹들간의 관계와 연속성을 파악하여 이것이 드러나도록 다이어그램(예를들면 연속적인 축)을 만들어 봅니다.
바라보는 관점에 따라 이러한 다이어그램이 여러 개가 나올 수 있습니다. 결국 만들고자 하는 것은 행동 특성에 기반한 맵 상에 놓인 사용자 그룹들입니다.


2. 리서치 범위 설정하기 (로젠펠드에 의하면 경영 전략적 판단이 개입하는 영역이라고 합니다)

2-1.조사할 행동 특성 그룹 선택
참여자들의 판단에 따라 행동특성 그룹을 선택합니다. 클라이언트도 참여하여 전략적인 선택을 하기도 합니다. (우리 제품은 이 그룹의 사용자를 타겟으로 해야 해!)

2-2.영역 추가보완
다이어그램(혹은 맵?)으로 표시할 때의 장점은 전체적인 관계속에서의 상대적 위치를 파악할 수 있다는 것이고, 따라서 비어있다고 생각되는 영역을 추가할 수 있습니다.


3.인터뷰 준비

이제 인터뷰를 할 대상 그룹을 결정할 수 있게 되었으며, 대상 그룹에 따라 인터뷰 준비를 진행하면 됩니다.


정리하면

기존에 pxd에서 사용자 조사를 하기 전에 기초 리서치를 진행하고 사용자 조사 준비를 하는데 이 과정에 좀 더 체계적으로 분절될 수 있는 방법을 제시하고 있는 것 같습니다. 정성 조사를 주로 하는 pxd로서는 조사 대상이 적은 경우가 많기 때문에 조사 대상 방법에 대한 객관성을 요구받는 경우가 많은데 멘탈모델 기법의 활용으로 이를 보완할 수 있을 것 같습니다.


다음에 인터뷰하여 패턴을 찾는 과정(멘탈모델(2)-행동중심의 디자인접근법)을 더 정리해보겠습니다.
[참고##조사 방법##]

팀블로그 pxd Story 구독 방법  블로그 글은 각 개인의 생각이며 피엑스디와 다를 수 있습니다.


Trackback 1 Comment 0
Ad Test...