태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.


'Re-design!'에 해당되는 글 31건

  1. 2017.05.19 [design hacking] 다음 뉴스 자동요약 바로 보기 by 無異
  2. 2017.04.10 버스 정류장 도착 정보 안내판의 번호 정렬 규칙 by 無異
  3. 2017.04.05 [Design Hacking] 네이버 뉴스 감성 아이콘 사용자 반응 시각화 (4) by 無異
  4. 2017.04.05 UI 디자이너의 위기지학, Design Hacking을 통해 코딩 배우기 by 無異
  5. 2016.11.22 지도 기반의 버스 앱 리디자인 by 無異
  6. 2016.10.31 버스 승차 알림과 맥락 기반의 implicit interaction (5) by 無異
  7. 2016.06.16 트위터 퍼소나 데모 페이지 (2) by 無異
  8. 2016.05.19 데이타 기반 퍼소나 - 트루밸런스 by 無異
  9. 2016.05.04 아이와 함께 만드는 한글 공부 키보드 (12) by 無異
  10. 2016.04.18 트위터 사용자 유형 - 데이타 기반 퍼소나 by 無異
2017.05.19 19:04

[design hacking] 다음 뉴스 자동요약 바로 보기

다음 뉴스에는 기사를 자동 요약해 보여주는 기능이 있습니다. 예전에 야후가 summly 를 인수하면서 이런 뉴스 요약 서비스가 여러가지 의미로 화제가 되었었죠.

다음 뉴스 자동 요약의 품질은 초기에는 만족스러웠던 기억이 나는데요. 오히려 최근들어 기사 앞 문장만 그대로 따오는 경우가 많아서 좀 의문이 들긴 합니다. (두괄식으로 기사를 잘 써서인지) 그럼에도 저처럼 바쁘고 게으른 사람에게는 상당히 유용한 기능입니다.

다음 뉴스 자동요약 기능


버튼 누르기도 귀찮아요. 그냥 펼쳐 보여주세요.

그런데 사용이 그리 편하지 않습니다. 처음에는 클릭하는 방식이었는데 번거럽다는 의견이 있었는지 그나마 현재는 마우스오버만 하면 보여집니다. 이런 기능을 쓰는 사람들 속성을 잘 모르는 것 같아요. 게을러서 버튼에 마우스 옮기는 것도 귀찮거든요. 당연히 처음부터 펼쳐 보여주면 좋겠습니다. 왜 그렇게 안 할까 생각해봤는데 두 가지 정도 이유가 있지 않았을까 싶습니다.


1. 모든 사람이 요약이 펼쳐 보여지는 것을 좋아하진 않는다.

모든 사람에게 자동 요약이 보여지면 당연히 싫어하는 사람이 있습니다. 그래서 사용자 선호에 따라 선택하도록 해야 합니다. 그러면 복잡해 지겠죠. 그런데 별도의 설정 없이도 자동 요약 버튼을 눌러 한 번 펼쳐보면 브라우저 로컬DB에 상태를 저장하고 이 후에도 계속 펼쳐 보여주면 됩니다. 싫으면 토글로 다시 닫으면 되고요. 이런 기능 사용은 기사 자체 보다는 사용자 성향에 더 영향이 있어 쓸 사람은 계속 쓸 것 같거든요.

다만 자동 요약은 기사 본문과 확연히 다르면서 너무 주의를 끌지 않아야 합니다. 요약을 보고 싶지 않으면 별다른 인지 비용 없이 스크롤을 내려 방해 없이 본문을 읽을 수 있어야 합니다.


2. 요약이 바로 보여지면 본문은 안 읽고 바로 나가버릴 수 있다.

두번째는 서비스 제공자 입장에서 요약만 읽고 바로 나가서 사용자를 잃게 되는 걱정이 있을 수도 있을 것 같습니다. 테스트 결과가 있는지 모르겠지만 별로 영향은 없지 않을까 싶습니다. 요약과 상관없이 기사가 좋으면 계속 읽고 나쁘면 바로 닫으니까요.


자동 요약 바로 펼쳐 보기


자동 요약을 본문 앞에 바로 펼쳐보여주기

현재의 팝업 방식보다는 본문 앞에 위치하는 것이 읽기 수월합니다. 자동 요약을 별도 div 요소로 감춰두었다가 마우스 오버시 보여주는 방식인데요. .layer_summary 요소를 prepend를 이용해서 기사 본문 앞으로 옮기고 항상 보이도록 합니다. 그리고 스타일에서 글 상자 형태를 만들어 주고 자동요약이라는 레이블을 붙여줘서 본문과 구분되도록 했습니다.

$(“.article_view section”).prepend($(“.layer_summary”));
$(“.layer_summary”).prepend($(“<span class=summary_label>자동요약</span>”))


코드 https://codepen.io/taekie/pen/gWyOzW


사용자 주의를 뺏는 다단 사용하지 않기

글 줄 길이가 너무 길면 가독성이 떨어지기 때문에 문단 폭을 제한합니다. 넓은 모니터에 여백이 남으면 뭐라도 넣고 싶어집니다. 수익 광고나 사이트에서 벗어나지 않도록 잡아 둘 수 있는 인기 컨텐트 링크를 놓기에 딱 좋습니다. 하지만 이런 요소들은 기사를 읽는데 방해가 됩니다. goodui 에서도 가장 첫번째로 멀티컬럼을 사용하지 말라고 얘기합니다. 다양한 기능보다도 우선 주의를 분산 시키지 않고 메인 컨텐트에 집중 할 수 있도록 만들어 주는 것이 좋습니다.


기사에 집중 할 수 있도록 하는 디자인


저는 개인적으로 부차적인 다단을 없애고 기사에 집중할 수 있도록 디자인을 바꿔서 사용합니다. 이 부분은 광고 수익과 직접적인 관련이 있으니 코드를 공유하기보다 숙제로 남겨두겠습니다. 

다음에서도 뉴스에서만이라도 다단이 아닌 다른 방법을 고민해보면 좋겠습니다. 그렇다고 네이버 뉴스처럼 광고를 기사 머리에 딱 박아 놓는 것은 사용자는 물론 기사한테도 정말 예의가 아니라고 생각합니다. 네이버 뉴스도 좀 적당한 타협점을 고민해 주면 좋겠습니다.



[참고##Design Hacking##]


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


Trackback 0 Comment 0
Ad Test...
2017.04.10 13:00

버스 정류장 도착 정보 안내판의 번호 정렬 규칙

버스정보시스템(BIS)을 통해 내가 탈 버스를 마냥 기다리지 않고 언제 올지 예측할 수 있게 되면서 삶의 질이 높아졌습니다. 하지만 정작 정류장에 설치된 전광판에 내가 탈 버스 번호가 언제 나올지는 예측할 수 없습니다. 도대체 규칙을 모르겠거든요.


버스정보안내단말기(BIT)에서 내가 탈 버스 번호는 도대체 언제 나오는걸까?

지하철이나 자가용을 주로 이용하는 분들은 번호가 당연히 번호 순서대로 나오는 게 아닌가 생각할 수 있는데요. 그렇지 않습니다. 아래 사진을 보고 어떤 순서인지 생각해보세요.


버스가 많지 않은 정류장은 별로 문제 되지 않는데 버스가 많은 곳은 사정이 다릅니다. 표시할 버스는 많고 표시할 수 있는 정보량은 한정되어 있으니 페이지를 나눠 순환 표시하는데요. 규칙이 명확하면 어느 페이지에 나올지 예측하여 인지 비용을 줄일 수 있지만 규칙을 모르면 번호를 하나하나 확인하며 페이지가 바뀌길 기다려야 해서 끔찍합니다.

저도 매번 모든 번호를 일일이 확인했습니다. 번호 표시에 규칙이 있다고는 생각을 못했거든요. 처음에는 상식적으로 번호 순이겠거니 생각했지만 규칙에 어긋나는 예외가 많아서 버스 정보가 업데이트 되는 순서에 따라 불규칙하게 표시되는 거라고 생각했습니다.

그러다 얼마 전 번호 표시에 나름 규칙이 있다는 걸 발견했습니다.


현 서울시 BIT 번호 표시 규칙을 알아보자


1. 개발 편의적인 사전식 문자열 정렬

버스 도착 안내에는 크게 번호 순과 도착 순 방식이 있는데요. 현재도 일부 단말이 도착 순으로 운영되고 있습니다. 나름 명확한 원칙이지만 기다리는 사람 입장에서는 도움이 안 됩니다. 순서 예측이 불가능하니 내가 탈 버스가 언제 표시될 지 알 수 없습니다. 그래서 점차 번호 순으로 교체하고 있다고 합니다.

일반 사람이 익숙하고 상식적으로 생각할 수 있는 순서는 번호 순입니다. 버스 번호 기본 체계가 숫자로 되어 있으니까요. 하지만 안내판의 번호 순서는 우리의 상식과는 다릅니다. 얼핏 번호 순 같기도 한데 안내판에는 3012가 401보다 앞에 나옵니다. 이건 도대체 뭔가요?

문자열 정렬을 사용하기 때문인데요. 개발자 말고 문자열 정렬이라는 말을 들어보신 분 있나요? 문자열 정렬은 숫자가 아닌 문자로 간주하여 앞자리부터 비교해 사전식으로 순서를 정하는 방식입니다. 첫자리 3이 4 보다 유니코드(ASCII)의 앞에 있으니 3012이 401 앞에 와야 한다는 거지요. 맨 처음에 나올 것 같은 3번 마을 버스가 맨 뒤에 표시되는 것도 같은 이유입니다. 심지어 3번 마을 버스는 8번 마을 버스 다음에 나오는데요. "강남08, 서초03"의 "강"은 숫자보다 문자 코드 뒤에 위치하고 "서"보다는 앞에 있으니까요.

일반인은 익숙지 않은 문자열 정렬을 굳이 사용한 맥락상 장점이 무엇일까 곰곰이 생각해봤는데요. 제 생각의 범위로는 전혀 모르겠습니다. (권역별 정렬을 위한 것이라는 주장에 관한 부분은 아래 추가로 적었습니다) 버스 번호에 "강남03", "M5422" 처럼 숫자 외에 문자도 포함하기 때문에 변수를 문자열로 지정해야 하는데요. 개발 편의를 위해 문자열의 기본 정렬(sort)을 그냥 사용한 게 아닌가 하는 짐작 말고는 다른 이유가 떠오르지 않습니다. 설마 개발에서 예외 처리 두세 줄 하는 게 귀찮아서 모든 서울 시민이 고통받는 것인가요?


2. 다단 목록의 지그재그 나열

일반인의 순서 vs 버스 안내판의 순서

문자열 정렬이란 걸 알고 봐도 이상한데요. 왜 다음에 와야 할 번호가 안 보일까요? 2단으로 배치된 번호가 일반적인 И 이 아닌 Z 순으로 나열되어 있기 때문입니다. 목록을 지그재그로 나열하면 시선 이동 거리가 길어지고 다음 줄로 시선이 되돌아왔을 때 다음 열이 어디인지 헷갈릴 수 있어 좋지 않습니다. 그래서 정상적인 다단 목록에서는 И 방향 정렬을 사용합니다.

문자열 정렬과 Z 정렬 조합으로 일반인이 예상하는 순서와는 전혀 다른 형태가 되었던 것입니다.


3. 곧 도착 버스의 표시 제외

앞의 정렬 규칙을 우리 같은 평범한 사람이 이해하지 못하더라도 매일 타는 버스의 번호가 항상 같은 곳에 표시되기라도 하면 찾기 쉬웠을 텐데요. 그렇지 않습니다.

"곧도착"에 표시되는 버스는 중복되지 않도록 상단에서는 누락 시킵니다. 아래 6000번 앞의 540번이 위에는 보이지 않습니다. 540번은 "곧도착"에서 표시하고 있으니까 안 보여주겠다는 겁니다.

이 때문에 매번 버스 번호의 표시 위치가 달라집니다. 도대체 왜 이런 규칙을 굳이 추가 했는지 정말 궁금합니다. 페이지 로테이션 시간을 줄여줄 수 있어서요? 별로 효과 없습니다. 덕분에 몇 년간 버스를 타면서도 버스 번호는 불규칙하게 표시된다고만 알았지 규칙이 있으리라고는 생각하지 못했습니다. 화면도 계속 바뀌고 경우에 따라 아래 6411번처럼 "곧도착"과 상단에 같이 표시될 때도 있는 헷갈리는 표시 방법 때문에 규칙을 알기는 더욱 어렵습니다.


상식에 맞는 정보 디자인

어려운 해결이 필요한 게 아니라 상식에 맞는 디자인이 필요합니다.

1. 문자열이 아닌 숫자 순으로 정렬

내가 탈 번호가 이미 지나갔는지 조금 기다리면 나올지 쉽게 예측할 수 있습니다. 문자를 포함하는 번호를 위해 예외 처리를 한 소팅 함수를 만들어 사용해 주세요.


2. 다단 목록 N 정렬

지그재그 Z 정렬이 불편하고 나쁜 걸 몰라서가 아니라 이것도 개발 편의 때문인 것 같습니다. BIT 말고도 많은 서비스가 이렇게 표시하고 있거든요. 다들 반성하고 고쳐 주세요.


3. "곧도착"과 상관없이 모든 버스 번호 표시

대부분 같은 정류장에서 같은 버스를 탑니다. 항상 타는 버스가 같은 페이지 같은 위치에 표시되면 찾기 쉽습니다. 혹시 "곧도착" 버스의 도착 시간이 1분 이내 초 단위라서 오차로 오해를 줄 수 있는 게 걱정이라면 도착 시간을 "곧도착"으로 표시해 주세요. 

(정정- 곧도착은 전 정류소 통과 후 2분내 도착 예정일 때 표출된다고 합니다.)


공공 서비스 디자인 사용성 검수 절차가 필요합니다

전광판의 번호 표시 규칙을 알게 되었지만 전혀 기쁘지 않습니다. 화가 납니다. 시민의 편의를 위해 시민의 세금으로 운용되는 공공 서비스가 도대체 왜 이렇게 만들어졌는지 왜 이렇게 방치하는지 이해되지 않습니다. 기본적인 사용 편의성 검증조차 없었기 때문이라고 생각합니다. 용역을 주고 개발자 맘대로 만들게 해서도 안되고 전문가의 형식적인 자문으로 넘어가서도 안됩니다. 실제 사용 맥락에서 실제 사용자를 대상으로 한 사용성 평가, 검수 절차를 개발 규정에 포함 시켜야 합니다.




업데이트 1.


현재 정렬 방식은 권역별 정렬을 고려한 것인가?

현재의 문자열 정렬이 개발 편의적일 뿐 사용자에게는 혜택이 없는 것처럼 글을 써서 댓글로 반대 의견들을 남겨 주셨습니다. 장단점이 물론 있음에도 누락한 것은 오해의 소지가 있어 해당 내용을 추가합니다.

서울시 버스는 2004년 권역별 노선 및 번호 체계로 개편하였습니다. 운행 구간거리에 따라 간선,지선 등 버스 종류에 따라 색상을 구분하고, 서울을 8개 권역으로 나눠 숫자를 부여하고 출발권역-도착/회차권역-일련번호로 구성된 번호체계를 도입합니다.

덕분에 앞두자리 숫자로 대강의 운행 노선을 예상할 수 있습니다. 이론적으로 앞 두자리 권역이 일치하면 비슷한 노선을 운행할 가능성이 큽니다. 그래서 번호 순으로 정렬하면 자연스레 비슷한 구간 노선끼리 그룹핑이 됩니다. 하지만 동일 지역을 운행해도 그것이 버스의 도착지일 수도 출발지 일 수도 있기때문에 번호 순 정렬을 통해 같은 지역 버스가 항상 묶이는 것은 아닙니다. 


2권역에서 다른 권역으로 운행하는 버스의 경로. 현 정류장에서 부터의 경로만 표시하고 중복 경로 제거.


같은 자리수인 간선, 지선 끼리는 숫자 정렬이나 문자열 정렬 상관없이 동일 권역으로 묶여 소팅 됩니다. 다만 앞 두자리 권역별로 소팅하면 내가 가려는 목적지에 같은 권역의 간선, 지선 버스가 있을때 무리지어 나오므로 편리합니다. Binseop Ko님이 댓글로 알려주신 사례가 그렇습니다. 그래서 주로 이용하는 버스가 정보안내판에 묶여서 표시되고 있었던 분들은 현재의 문자열 정렬 방식이 보다 유용하다고 느끼셨을 겁니다. 


지선과 간선버스가 동일 노선을 공유하는 경우


그런데 실제로는 이런 사례가 많지 않습니다. 작년에 여러 버스가 많이 몰리는 주요 정류장 들을 샘플링하여 조사해 봤는데요.(정류장 기반 노선도 이용) 이렇게 간선과 지선이 노선을 공유하는 경우가 드물었습니다. 우선 보통 큰 정류장은 중앙차로 정류장으로 지선버스가 정차하지 않는 경우가 많아 노선을 공유해도 같이 표출되는 경우가 줄어듭니다. 위처럼 목적지가 같더라도 두번째 도착지권역이 같은 경우는 묶이지 않습니다. 아래처럼 같은 권역이라도 실제로는 넓은 지역이라 같은 노선을 공유하지 않는 경우가 많습니다. 노선을 공유해도 모든 구간이 일치하는게 아니라 일부 구간이 겹치는 경우가 대부분입니다.

그래서 문자열 정렬로 내 목적지의 지선,간선 버스가 묶여서 표시되는 혜택을 보는 사용자 보다는 그렇지 않은 사용자가 훨씬 많게 됩니다. 이론적으로는 권역별 정렬을 하는 것이 장점이 있을 것 같지만 실제로 그런 경우는 일부이고 익숙치 않은 순서로 오히려 헷갈려하는 사용자가 더 많을 것입니다. 오히려 반대로 목적지와는 관계 없는 버스가 순서에 끼어드어 잡음으로 보일 수 있고요. 

디자인을 하면 항상 이런 사용자간의 편익 차이가 생기기 때문에 퍼소나 방법을 사용해 어떤 사용자에게 보다 집중할 것인지 결정을 내리게 됩니다. 그래서 쉽게 숫자 순이 더 좋은 선택이라고 주장했던 것인데요. 어떻게 되었건 현재 방식으로 혜택을 받고 있는 사용자들이 있고 이것을 바꾸게 되면 다시 불편해 질 수 있기 때문에 간단치는 않다고 생각합니다. 실제 의사 결정을 해야하는 담당자라면 결론으로 썼던 것처럼 다양한 실제 사용자의 의견(사용성평가)을 듣고 더 많은 고민을 해주시길 바랍니다.


암튼 그래서 현재 방식은 이런 권역별 정렬을 고려한 것이었을까요? 그렇지 않습니다. M6427은 동일한 번호인 6427과 거의 같은 노선을 운행하는 광역급행버스입니다. 하지만 이 두 버스는 묶여 표시되지않고 문자열 정렬로 인해 멀리 떨어져 있습니다.



추가 업데이트 2. 1027.4.18

서울시 응답소 민원 답변을 받았습니다

글을 쓴 이유는 사실 화가 나서이기도 하지만 :) 단순히 불만을 토로하려는게 아니라 개선이 꼭 되기를 바랐기 때문인데요. 민원을 요청하기 전에 내용을 정리하려는 목적이었습니다. 트위터를 @seoul_eds  통해 민원을 접수하고 답변을 받았습니다.

http://eungdapso.seoul.go.kr/Community/viewLongText.jsp?key=3A5595E5D847AB456C2BCC06852C3BD55AE19ED2D741D881530365E7E5F4A2A7

 

현재 서울특별시 교통정보과에서 설치한 1200여대의 BIT(가로변정류소 독립형, 중앙정류소 승차대 걸이형)와, 2014년에 민간회사인 KT가 설치한 2000여대의 BIT(가로변정류소 승차대 걸이형)가 있다고 합니다.


1. 번호순 정렬 

검토를 중 이라고는 하지만 조금 부정적인 듯 하네요 :) 하지만 2,3이 반영되면 크게 문제되지 않을 수 있을 것 같습니다.

2. N정렬

원래  N정렬이 원칙이고 일부 Z정렬되는 BIT가 확인되어 일제조사를 통해 N정렬로 교체 추진계획이라고 합니다.

3. 곧도착 정보 개선

정보불일치 문제로 채택하지 않는다고 답변 주셨습니다. 

그런데 설명이 잘 이해가 되지 않습니다. 도착시간이 실시간 정보가 아니어서 상단에 계산된 예측 도착시간을 표시하면 실제 도착 시간과 일치하지 않아 문제가 될 수 있다는 것 같습니다. 그래서 도착 시간을 부정확한 예측 시간이 아니라 "곧도착"으로 표기하면 된다는 것이었는데요. 다시 확인해 보도록 하겠습니다.

담당자님, 의견 들어주시고 개선을 위해 수고해 주셔서 고맙습니다.


추가 업데이트 3.  2017.5.22

정류장 BIS 개선 반영되었습니다

최근 BIS 점검 중이라는 안내를 봤는데요. 
고속터미널 근처의 정류장에는 1. 번호순 정렬과 2. N정렬이 반영되었습니다. 

고맙습니다. :)



[참고##정보디자인##]



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


Trackback 0 Comment 0
Ad Test...
2017.04.05 07:54

[Design Hacking] 네이버 뉴스 감성 아이콘 사용자 반응 시각화

최근 네이버 뉴스에서는 기사에 대한 사용자 반응을 공감해요에서 감성 아이콘으로 변경했습니다. http://blog.naver.com/nvr_design/220971828846

페이스북의 감정 리액션을 따라 한 것 같은데요. 참여 사용자의 수를 보면 상당히 호응이 좋은 것 같습니다. 기사라는 성격에 맞게 훈훈해요. 후속 기사 원해요 라는 선택도 적절해 보입니다.

하지만 참여한 사용자들의 반응을 보여주는 방식이 아쉽습니다.


기사에 대한 독자의 주된 감정이 드러나게 하기


기사의 상단에는 최다 득표를 한 감정 아이콘 2개를 노출합니다. 하지만 그 비율이 어떤지는 알 수 없습니다. 하단의 감성 아이콘은 얼마나 많은 사용자가 반응했는지 숫자로 정보를 보여주는 기능과 아이콘을 눌러 참여하는 액션 버튼으로의 두 가지 기능을 동시에 하고 있습니다. 

네이버 뉴스에서의 감성 아이콘 표현


액션 버튼에 덤으로 정보도 있다고 생각하면 이해를 할 수도 있지만 기왕 정보를 보여주는 것이라면 쉽게 표현이 되면 좋겠습니다. 독자 중에서 이런 반응에 참여하는 비율이 보통 20% 이하인데요. 80%의 사용자에게는 다른 사람들이 어떻게 반응했는지 확인하는 상태 표시가 더 의미가 있으니까요.

사용자의 반응이 잘 눈에 안 들어오는 건 숫자를 뇌에서 해석하여 비교해야 하기 때문인데요. 전 주의처리 속성을 이용해 시각화하면 좋겠습니다. 아이콘을 사용하고 있으니 득표 수에 따라 크기를 달리하는 걸 가장 먼저 생각해 볼 수 있는데요. 가장 많은 득표를 한 아이콘을 기본으로 두고 다른 감정을 상대적으로 작게 표현하도록 해봤습니다. 주된 감정을 알고 싶은 거지 정확한 비율을 알고 싶은 건 아니라 득표가 0이라고 안 보이게 하기보다는 최소를 50% 정도로 잡았습니다. 그래프에서 양을 제대로 비교하려면 크기는 2차원이니까 제곱 근에 비례하게 조정해야 하겠지만 그렇게까지 하지는 않았습니다. :)
이 정도만 조정을 해도 기사에 대한 독자들의 주된 감정이 무엇인지 바로 눈에 들어옵니다. 상단에서 화나요와 슬퍼요 두개 표시된 것으로는 두 감정이 비등한지 아닌지 알 수 없습니다. 하지만 이렇게 전체 감정의 비율을 시각화 함으로써 화나요가 다른 감정 등에 비해 월등히 우세한 반응이라는 것이 바로 드러납니다.

득표가 0인 경우는 회색으로 확실히 대조를 만드는 게 좋습니다. 아래는 아이콘이 가운데 정렬, 위에는 하단 정렬되어 있습니다. 1차원 바차트가 아니더라도 크기를 비교하는 거라면 위처럼 정렬 하는 게 좋습니다.


사용한 코드를 수정해서 나만의 디자인을 연습해 보세요.  http://codepen.io/taekie/pen/bqzmPN

아이콘을 :before pseudo 요소를 이용해서 그리고 있는데요. 보통은 DOM 객체의 스타일을 변경하지만 :before는 실제 DOM 요소가 아니라 CSS 선택자로 직접 선택할 수가 없습니다. 할 수 없이 문서의 스타일 객체에 :before 를 재정의해 주는 주었습니다.

$(function(){
  setTimeout(redesign,500);
})

function redesign(){
//좋아요
  var max_count=1;
  $(".u_likeit .u_likeit_list_count").each(function(){
	var count=parseInt($(this).text());
  if(count>max_count) max_count=count;
	});
  $(".u_likeit .u_likeit_list_count").each(function(i){
	var count=parseInt($(this).text());
  var size=count/max_count*0.5+0.5;
  var opacity=count/max_count*0.8+0.5;
  var gray=0;
  if(count==0) gray=1;
	var style="<style>.u_likeit_list:nth-child("+(i+1)+") a:before{transform:scale("+size+");opacity:"+opacity+";filter:grayscale("+gray+");}</style>"
$(style).appendTo('head');
	});
}


훈훈한 기사를 모아보면 좋겠어요

기사에 직접 사용자의 감정 반응을 넣도록 한 것 좋은 시도라고 생각합니다. 사실 대부분의 뉴스가 화나고 슬픕니다. 그런 소식들이 기삿거리가 되니까요. 하지만 가끔 훈훈한 뉴스를 보면서 위안을 얻고 싶을 때가 있는데요. 데이터가 쌓이면 이런 독자 감정 반응으로 검색해서 모아 볼 수 있는 기능도 제공되면 좋겠습니다.





[참고##Design Hacking##]


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


Trackback 0 Comment 4
Ad Test...
2017.04.05 07:50

UI 디자이너의 위기지학, Design Hacking을 통해 코딩 배우기

pxd에서는 2017년을 UI 디자이너가 코딩하는 원년으로 삼기로 했습니다. 저 혼자 정한 거지만요. :)
UI 디자이너가 코딩을 배워야 하는 이유에 대한 글들은 많이 보셨을 텐데요. 저는 UI 디자이너의 의도적 수련에 필요한 능력으로써 코딩을 배우면 좋겠습니다.
코딩을 배워야겠다고 생각하는 디자이너는 많아도 새로운 걸 배운다는 부담감이 커서인지 주변에서 실제 코딩을 배우는 분은 별로 없습니다. 그래서 같이 따라 하면서 실질적으로 코딩을 배울 수 있는 디자이너의 코딩 수련장(workbook) 형식으로 글을 써보려고 합니다.

UI 디자이너의 의도적 수련과 피드백

디자이너로서 전문성을 키우고 성장하는 데는 새로운 방법과 지식을 습득하는 것도 필요하지만 직접 디자인하고 그것에 대한 피드백을 통해 학습하는 디자인 수련이 더욱 중요합니다. 김연아 같은 훌륭한 선수가 되는데 필요한 요건으로 피나는, 뼈를 깎는 같은 수사의 노력과 훈련을 빼놓지 않는데요. 스포츠 같은 분야는 이런 수련의 모습이 머리속에 쉽게 그려지지만, UI 디자이너가 뼈를 깎는 수련을 하는 모습은 잘 연상되지 않습니다.
연습의 행위 보다 피드백에 차이에 기인한다고 생각합니다. 전자의 경우는 점수를 얻거나 승부를 가리는 규정(측정)이 명확해서 기량이 향상되고 있는지 피드백이 즉각적이고 명료합니다. 

반면에 UI 디자인 자체로써는 사용자가 사용하는 제품이 아니기 때문에 피드백을 얻는 데 불리합니다. 개발자의 구현이 있어야만 사용자가 접하고 피드백을 받을 수 있어 응답 주기가 길어집니다. 디자인과 사용자 피드백 사이에 다양한 변수가 존재해서 해석석하는데 모호함이 생깁니다. 다양한 사용자가 각자의 다양한 맥락에서 디자인을 판단하기 때문에 어떤것이 유의미한 피드백인지 판단하기가 어렵습니다.

디자인 에이전시에서 수행하는 과제들은 디자인과 개발 단계가 분리되어 있고 제품 출시까지의 주기가 길어 디자인에 대한 사용자 피드백을 얻을 기회가 적습니다. 그래서 과정에 leanUX 방법과 프로토타이핑을 적극적으로 도입하려고 하지만 일정이나 비용 제약으로 적용할 수 있는 과제는 제한적입니다.

구체적인 피드백을 제때 받아야 개선을 하고 실력을 향상할 수 있는데요. 일을 많이 해서 경력이 쌓인다고 실력이 늘지 않습니다. 일은 일이고, 실력을 키우려면 개인적인 노력이 필요합니다. 그럼 뭘 어떻게 노력해야 하나요? 그래서 UI 디자이너의 의도적 수련 방법으로 Design Hacking을 제안합니다.


나를 위한 UI 디자인, Design Hacking 하기

수련에 도움이 되는 구체적인 피드백을 받으려면 변수와 범위를 가급적 제한해야 합니다.

1. 기존의 것을 개선하기

뭔가 세상에 없던 혁신적인 것을 만드는 것이 좋은 디자인이라고 생각하고 강박적으로 새로운 것만 찾으려고 하는 경우가 많은데요. 하지마세요. 검증(측정)해야 하는 범위가 너무 넓어져서 수련 방법으로는 적합하지 않습니다. 

디자인 수련은 문제를 찾고 해결하는 과정을 연습하려는 것인데 우선은 기존 문제의 해결 부분에 집중하는게 좋습니다. 사람들이 잘 쓰고 있어서 필요가 검증된, 항상 시험에 나오는 기출 문제부터 시작하세요. 범위를 보다 제한해서 하나의 화면, 그 안에서도 하나의 모듈, 하나의 기능을 선명한 목적을 가지고 개선해보는 게 좋습니다. 변수가 통제되어 기존 것보다 좋아졌는지 아닌지 대조가 명확해야 피드백의 가치가 있습니다.


2. 디자인 해킹으로 동작하는 프로토타입 만들기

페이퍼 프로토타입이라도 만들어보라고 하는 건 안 만들어서 피드백이 아예 없는 것보다는 낫기 때문입니다. 가급적 충실도가 높은 프로토타입으로 실제 맥락에서 실제 데이타를 가지고 직접 사용해 볼 수록 보다 좋은 피드백을 얻을 수 있습니다. 아무리 대박이 날 좋은 아이디어라도 컨셉 스케치만으로는 배우는 게 없습니다.

그렇다고 미천한 코딩 실력으로 실제 사용 가능한 서비스 프로토타입을 만들기는 어렵습니다. 프로토타이핑 툴을 이용해서 플로우나 마이크로 인터랙션을 확인 해보는 것은 여기서 말하는 동작(working)에 해당하지 않습니다. 기존의 동작하는 서비스를 여전히 동작하는 범위 안에서 수정해서(hacking) 사용해보고 평가해보는 경험을 많이 해보는 게 좋습니다.
그래서 코딩을 배우세요. 뒤 단에서 서비스가 어떻게 돌아가는지, 시스템 프로그래밍을 하는 것은 기대하지 않습니다. 말단 인터페이스의 시각적인 정보 디자인과 인터랙션만이라도 내가 생각하는 디자인으로 바꿔서 현실화해보고 싶다는 분명한 목적을 가지고 코딩을 배우면 좀 더 수월하게 배울 수 있습니다. 코딩을 체계적으로 배워서 나중에 뭘 해보겠다는 접근 보다 실질적인 필요를 위해 우선 베껴서라도 돌아가게 하고 나중에 원리를 이해하는 방법이 실용적입니다.


3. 디자인 위기지학

UI 디자인을 배울 때 사용자는 내가 아니라는 것을 강조합니다. 특히 디자이너나 개발자는 사용자가 아니라고요. 물론 디자인을 하는데 실제 사용자를 조사하고 이해하는 과정이 중요합니다. 그리고 어렵습니다. 그래서 안 하려고요. 이건 따로 연습하세요. 물론 대부분 과제의 사용자는 내가 아닌 경우가 많습니다. 하지만 일 하는 게 아니라 배우려는 거니까요. 내가 사용자인 서비스로 우선 디자인의 핵심에 집중해서 연습하는 게 좋습니다. 

사용자 이해 - (문제 정의 - 문제 해결) - 사용자 피드백

힘든 수련을 계속해 나가려면 보상이 필요합니다. 내 문제를 스스로 해결하는 즐거움을 경험하는 것도 중요합니다. 나를 위한 디자인을 우선하고 남들에게도 적용할 수 있는지 확장하는 접근을 써보는게 좋습니다. 많은 문제들이 user centered design 보다 human centered design 이 제대로 안된 경우가 많거든요.


기존의 서비스를 사용하다 보면 아쉬운 점 한 두가지는 꼭 있죠? 내가 사용하면서 불편했던 바로 그 UI를 개선하는 연습을 할 것입니다. 내가 만족스럽지 못한 서비스는 크게 두 가지 경우 일텐데요.


내가 대상 퍼소나가 아닌 경우

정말 이거 하나만 고쳐주면 좋은데 왜 안하는지 이해 못하겠는 경우가 많죠? 디자인을 하면서 퍼소나 방법을 사용하는 이유입니다. 개개인의 요구사항을 다 들어주다가는 누구의 요구도 만족시키지 못 하게 됩니다.
하지만 마이너한 사용자층의 니즈를 발견하여 개선하는 것은 디자인 수련에서 앞서 얘기한 사용자의 이해 부분을 연습하는데 많은 도움이 됩니다. 그냥 내맘대로가 아니라 공통된 맥락과 니즈를 가지는 사용자 그룹을 객관화하는 훈련을 하면 다른 관점의 디자인을 할 수 있습니다.



다른 대상의 사용자를 위한 product hacking - Desiging Interactions


사용자들이 잠재적인 니즈를 아직 의식하지 못하는 경우

얼리어답터는 새로운 제품이 나오면 가장 먼저 그것을 사용해보고 싶어하는 그룹입니다. 하지만 그 앞에 시장에 제품(해결)이 없더라도 필요에 대한 감수성이 높은 Lead Users 사용자층이 있습니다. 관점은 다르지만 하라켄야의 욕망의 에듀케이션도 비슷한 의미라고 생각합니다. 몰라서 필요를 못 느끼는 거지 좋은 걸 한번 경험하게 되면 톱니바퀴 효과처럼 이전으로는 되돌아 가지 못합니다. 취향이나 상황이 다른게 아니라 필요에 대한 감수성이 남들보다 높은 부분은 좋은 해결만 찾아준다면 모두에게 도움이 될 수 있습니다.
서비스 제공자 입장에서도 이것을 하나의 사용자 피드백으로 바라보고 두가지 관점에서 대상이 아닌건 무시하고 좋은 건 수용하는 열린 접근을 하면 서비스를 건강하게 만드는데 도움이 됩니다. 애플이 시디아 같은 탈옥 기기를 위한 앱 스토어를 강력하게 제한하지 않는 것도 같은 이유라고 생각합니다.


Design Hacking 연재에서는 내가 잘 쓰고 있는 웹서비스의 불편을 느끼는 구체적인 한 부분을 선택해서 개선하고 직접 사용하고 평가하는 과정을 반복할 것 입니다. 우선은 제가 고쳐서 사용하고 있는 사례들을 소개하겠지만 궁극적으로는 여러분들과 함께 개선하고 싶은 서비스를 선정해서 함께 디자인 개선을 해보는 방식으로 진행하려고 합니다. 리디자인 결과 위주가 아니라 design hacking 코드를 공유해서 여러분 스스로가 자신에 맞게 고쳐보도록 할 것입니다. 나를 위한 디자인을 하면서 코딩을 배워보세요.


이제 바로 코딩을 시작합니다

우선 다음을 준비해 주세요.

크롬 브라우저

브라우저는 웹페이지의 HTML, CSS, Javascript 코드를 해석해서 보여줍니다. 크롬은 확장을 통해 서비스 제공자의 코드에 사용자 자신의 코드를 삽입하여 디자인을 바꿀 수 있습니다.
HTML은 실제 화면에 보여주는 내용과 tag로 요소의 구조를 정의한 코드입니다. CSS는 각 요소들이 어떻게 보여지는지를 정의하고 Javascript는 요소들을 동적으로 변화시키도록 하는 코드입니다. 코드를 보고 싶으세요? 크롬에서 보기>개발자 정보>개발자 도구 를 여세요.
매트릭스에 오신 걸 환영해요.


styler 확장

개발자 도구에서 요소의 스타일을 바꿔보거나 콘솔에서 코드를 실행해 보는 것만으로도 다양한 실험을 해볼 수 있습니다. 하지만 수정은 일시적일 뿐인데요. styler 확장을 이용하면 스타일을 변경하고 실행 코드를 삽입하는 규칙을 설정해서 특정 사이트의 디자인을 항상 변경할 수 있습니다. 구글 계정 동기화를 통해 다른 컴퓨터에서도 그대로 사용할 수 있어 편리하고요. styler는 여기 에서 설치하세요.


코딩을 배우고 오세요

설마 코딩을 가르쳐 준다고 생각한 건 아니죠?같이 문제를 풀어보자고 했지 가르쳐준다고는 안했어요. :) 코딩을 배울 수 있는 좋은 책과 좋은 온라인 교재가 많습니다.
온라인 강의는 egoing님의 생활코딩을 추천합니다. HTML, CSS, Javascript 수업도 들어보고 서점에 가서 자기 수준에 맞는 책을 골라 계속 참고하시길 바랍니다.
물론 먼저 따라해보고 코딩은 나중에 배워도 됩니다.



첫 디자인 해킹. 아직도 돋움으로 보세요?

저는 못생긴 폰트 사용하고 글자 작고, 줄간 간격 너무 좁고, 여백 좁아 답답하고 화가 나는 웹사이트 목록이 한 가득이에요. 타이포그래피도 UI 디자인에서 중요한 부분이지만 국내 웹사이트에서는 많이 간과하고 있는 것 같습니다. 이것도 디자이너가 코딩을 하지 못하는 것이 큰 이유라고 생각하는데요. 디자인 툴을 이용할 때는 타이포그래피 장인이어도 코드로 구현된 웹에서는 섬세하게 디자이너의 의도가 반영 되지 못하고 있는 것 같습니다. 폰트의 선택에서도 웹폰트가 많이 도입이 되고 있지만 전국민을 대상으로 하는 포탈 서비스에서는 요원합니다. 로마자에 비해 엄청나게 큰 한글 폰트의 용량 관계로 전 국민을 대상으로 하는 포탈 서비스에는 적용하기 어렵습니다. 가급적 모든 사용자의 컴퓨터에 미리 설치된 폰트를 선택할 수 밖에 없는데요. 그래서 네이버, 다음의 기본 폰트는 아직도 돋움입니다. 고조선이야 뭐야? 윈도우 95야?


다음 금융 http://finance.daum.net/ 사이트처럼 숫자가 많이 사용되는 곳에서는 특히 숫자 가독성이 중요한데요. 그리 만족스럽지 못합니다. 

기본 글꼴로 숫자는 arial을 사용하고 있는데요. 69 같은 글리프의 획이 8과 비슷하게 둥글게 말려있어 판독성(legibility)이 떨어집니다. 구분을 못할 건 아니지만 이런 작은 인지 부하가 쌓여서 가독성이 떨어지게 됩니다. 숫자 폰트 중에서는 스포카에서 lato를 좀 더 간결하게 커스텀한 스포카한산스를 선호하는데요. 이 폰트로 바꿔보겠습니다.


Styler 확장 사용법

크롬으로 사이트에 접속해서 styler 확장을 클릭하면 CSS와 JavaScript/jQuery 두개의 입력창이 보이는데요. 이곳에 코드를 적으면 상단에 보이는 도메인에 대해서는 항상 적용이 됩니다.


우선 모든 요소에 대해서 폰트를 강제 지정합니다. 스타일 부분에 아래 코드를 적어보세요. 아. 폰트는 미리 설치하셨죠?

* *{
  font-family:spoqahansans !important;
} 

주가의 상승 하락의 빨강과 파랑이 너무 자극적이어서 피곤합니다. 네이버도 마찮가지인데요. 조금 톤을 낮추는게 좋겠습니다.


.factor_up, .factor_up_type2 {
    color: #cc3e3e !important;
}

.factor_down, .factor_down_type2 {
  color:#477fd2 !important;
}


타이포그래피 측면에서 단위 기호 표기 방법 고민해 보셨나요?

비율 % 표시도 많이 사용되는데 숫자에 단위 기호가 딱 붙어 있는 게 보기 좋지 않습니다. 국제 단위 표기법에서 알파벳 기반의 단위는 수치값과 한 칸 띄우고 (123 cm, 45 kg) 기호 단위는 붙여 쓰는게 (67%, $89) 맞긴 합니다. 텍스트 표기의 원칙이 그렇다는 것이고 타이포그래피를 이용하면 좀 더 보기 편하고 잘 읽히게 만들 수 있습니다. 단위가 반복되고 맥락상 이해할 수 있으면 정보값이 잘 읽힐 수 있게 단위가 쉽게 구분 되는게 좋습니다. 이걸 서버단에서 처리하는 건 너무 귀찮은 작업이고 또 이런걸 신경 쓰는 사람도 별로 없으니까 그냥 다들 하는데로 내버려두는데요. 구현의 귀찮음의 비용을 사용자 인지 비용으로 떠넘기고 있는 셈입니다. 스크립트로 후 처리하는 방법을 적용해 주면 좋겠습니다.

저는 페이지가 로딩되고 난 후 숫자가 표시된 요소들에서 %를 <sub>%</sub>로 감싸고 sub 여백을 좀 주고 글자를 조금 작게하여 정보값인 숫자와 구분이 되도록 했습니다. (sub는 이런데 쓰는건 아니지만). 전문 개발자라면 제대로 된 쌈박한 라이브러리를 만들 수 있을 거라고 생각합니다. 관심을 가져주세요.

$(function(){
  $("span").each(function(){
	var num=$(this).html().replace(/%/,"<sub>%</sub>");
	$(this).html(num);
  });
});

sub{
  font-size:50%;
  margin-left:0.2em;
  vertical-align:bottom;
  opacity:0.6;
}

Before

After

TO-DO

이제 여러분 차례입니다. 여러분의 관점에서 디자인을 개선해 보세요. 도대체 뭐라는 건지 하나도 모르겠으면 개발자 도구 에서 속성값을 조금씩 고쳐보세요. 어떻게 하면 디자인이 망쳐지는지 어떻게 하면 더 나아지는지 직접 고쳐보고 경험해보는 게 좋습니다. 그리고 왜 이렇게 되는지, 뭘 더 할 수 있는지 궁금해지면 책을 보고 공부해보세요.

제가 디자인한 코드는 이곳에 공유 합니다. http://codepen.io/taekie/pen/xqBLab

여러분도 여러분의 디자인과 코드를 공유해 주세요.

[참고##Design Hacking##]



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


Trackback 0 Comment 0
Ad Test...
2016.11.22 11:24

지도 기반의 버스 앱 리디자인

버스 도착을 확인하는데 기존의 즐겨찾기 목록이 제게는 적합하지 않아 불편했습니다. 그래서 버스 앱을 지도 기반으로 만들어 사용하고 있습니다. 


맥락에 따른 버스 즐겨찾기 정보 디자인

기존 버스 앱의 즐겨찾기 목록에는 출근 할때 집 앞에서 타는 버스, 갈아타는 버스, 퇴근 할때 회사 근처에서 타는 버스, 갈아타는 버스, 수영장 갔다 집에 오는 버스들이 섞여 있습니다. 각 상황에서 버스가 두 개 이상 있다보니 목록은 점점 길어집니다. 긴 목록을 스크롤 하면서 내가 지금 탈 버스를 찾다 보면 화가 납니다. 내가 탈 것도 아닌 잡음이 되는 버스 목록을 왜 보고 있어야 하지? 앱이 아닌 비서라고 생각하면 불친절하거나 센스 없는 거거든요. 폰은 지금 내가 어디 있는지, 몇 시인지를 알고 있으니 내가 어떤 버스를 타려는 맥락인지도 알 수 있잖아요. 

네이버 지도의 버스 즐겨찾기에서 이름을 목적지에 따라 '회사','집' 등으로 변경해서 정렬해 볼 수는 있지만 그렇다고 지금 내가 타야 할 버스가 한 눈에 들어오지는 않습니다. 카카오 버스는 정류장 별로 그룹핑하여 보여주어 좀 더 보기 편하지만 내가 뭘 타야 하는지 바로 보이지 않는다는 점에서는 차이가 없습니다. 예외적이긴 하지만 전 갈아타는 같은 정류장에서 아침에는 회사로 저녁에는 집으로 가는데요. 같은 정류장이라도 다른 맥락이 섞여 있으면 오히려 방해되기도 합니다.

네이버 지도 버스 즐겨찾기, 카카오 버스 즐겨찾기


내가 지금 상황에서 타려는 버스만 알아서 잘 보여줄 수는 없을까요? 할 수 있습니다. 내가 있는 곳 근처의 즐겨찾기만 보여주는 정도의 간단한 필터링을 할 수 있습니다. 하지만 위치 정보가 정확하지 않거나 하면(실내에 있거나 하여) 실제 의도를 제대로 반영하지 못하는 false negative 오류가 생길 수 있습니다. 예외적인 상황을 고려하면 목록 형태보다 지도를 기반으로 보여주는 게 더 이점이 있습니다. 의도한 즐겨찾기를 잘못 보여주더라도 지도의 이동이나 줌 아웃을 통해 어렵지 않게 다른 즐겨찾기를 볼 수 있거든요. 

또 몇 정거장 전이라고 표시하기보다 지도 위에 표시하면 버스가 어디쯤 오고 있는지 직관적으로 알 수 있습니다.

즐겨찾기에 이용 시간대를 옵션으로 지정하면 같은 장소에서 다른 맥락인 경우도 걸러낼 수 있습니다. 같은 정류장에서 출퇴근 버스를 갈아타는 경우에도 퇴근 시간이면 출근 버스는 흐릿하게 표시하여 현재 맥락의 버스에만 집중하도록 했습니다.

도착 시간 정보를 표시하는데도 작지만 의미 있는 디테일이 있습니다. 같은 정류장에 여러 대의 버스가 있는 한 경우에, 그냥 번호순이 아니라 도착 시각에 따라 정렬해 먼저 올 버스가 먼저 보입니다. 어떤 버스가 먼저 올지 고민하지 않아도 됩니다. 보통 첫 번째, 두 번째 도착 시간을 함께 제공하는데 둘의 중요도가 같지 않습니다. 그다음 버스에는 관심없는 경우가 많으니 흐리게 표시하면 중요한 정보에 더욱 쉽게 집중할 수 있습니다. 버스가 가까이 와서 1분 이내에 도착하는 경우에 색을 강조하여 표시하면 인지 비용이 줄어듭니다. 


회사와 갈아타는 정류장에서의 현 위치를 기반으로 한 즐겨찾기 버스 도착 표시. 퇴근 시간대이므로 회사로 가는 버스는 흐릿하게 보인다.


즐겨 찾기 등록도 지도 기반으로 하면 보다 직관적으로 바꿀 수 있습니다. 기존은 정류장 번호를 먼저 검색하고 버스를 선택하거나 버스 번호를 검색하고 경로에서 정류장을 선택하여 개별적으로 등록하는 방식 위주였습니다. 무슨 DB 입력하는 것 같아요. (주변 지도에서부터 선택하는 방법도 물론 제공하지만요)

출근할 때 타는 버스, 퇴근할 때 타는 버스, 운동 갔다 집에 오는 버스 등 맥락에 따라 즐겨찾기를 하는 것으로 사고를 바꾸면 UI도 달라집니다. 탈 정류장을 선택하고 목적지를 지도에서 선택하면 해당하는 경로의 모든 버스를 찾아줍니다. 즐겨찾기에 왜 굳이 탑승시간을 지정할까요? 똘똘한 앱은 이제 내가 출근 시간에 이 정류장 근처에 가면 앱을 켜지 않아도 자기가 알아서 버스들의 도착 시간과 바로 승차 알림을 푸시로 알려줄 수 있게 됩니다. 


즐겨찾기 등록 UI. 버스 이용 맥락에 따른 즐겨찾기


주변 정류장 버스 확인

주변 정류장의 버스 정보를 확인할 때도 지도 기반이 보다 유용합니다. 즐겨찾기와 주변 정류장 모드를 나눌 필요가 없거든요. 지도에 내 위치를 표시하면 내가 어느 정류장 근처에 있는지 바로 확인할 수 있습니다.

높은 빌딩이 밀집한 곳에선 전파 반사로 GPS가 부정확해져 내가 길 건너편에 있는 것처럼 표시되는 경우가 자주 있습니다. 그래서 낯선 곳에서는 내가 어느 정류장에 서 있는지 지도를 봐도 헷갈리게 됩니다. 위치와 시선 방향을 함께 표시하면 이런 문제를 어느 정도 해결할 수 있습니다. 정류장에서 도로를 바라보면서 지도상의 내 위치를 확인해보면 실제 위치를 가늠하는 데 도움이 됩니다.



현재 정류장에서 버스 길찾기

코엑스에서 열리는 전시회에 가기 위해 고속터미널 앞의 버스 정류장으로 갔습니다. 여기에 바로 가는 버스가 많다는 걸 알고 있었거든요. 하지만 몇 번 버스를 타는지 까진 모릅니다. 정류장에서 버스 노선도를 하나하나 살펴보면서 코엑스 가는 버스를 찾으려다 포기했습니다. 노선도 디자인이 너무 나쁘거든요. 운 좋게 하나 찾더라도 더 빨리 오는 버스가 있진 않을지, 경로가 다르니 어떤 버스를 타는 게 더 빠를지 비교 선택이 불가능한 정보 형태입니다.


스마트폰의 대중교통 길찾기를 이용하면 스마트하게 몇 번 버스를 탈지, 어떤 버스가 먼저 올지 알 수 있습니다. 하지만 내가 지금 정류장에 있는 상황이라면 기존 앱은 그리 똘똘하게 정보를 보여주지는 않습니다. 

네이버 지도는 길찾기가 우선이라 버스 도착 시간은 알려주지 않습니다. 1, 2분 빨라 봤자 10분씩 더 버스를 기다려야 하면 아무 의미 없잖아요. 

그래서 다음 지도는 버스 도착 시간을 함께 표시해 줍니다. 자 이제 버스 검색 능력 시험을 보겠습니다. 아래 검색 결과를 보고 다음 물음에 답하시오. "뫄뫄는 지금 고속터미널 정류장에 서있다. 코엑스 전시장에 가려면 어떤 버스를 타는게 가장 좋은가?"


네이버 지도 앱, 다음 지도 앱 대중교통 길찾기

정답을 찾았나요? 정답을 찾는데까지 시간은 얼마나 걸렸나요? 

가장 빠른 35분 걸리는 401번 버스를 탈까요? 13분 기다려서?

아니면 그다음 1분 느리지만  4분 58초 후 도착하는 3414번 버스를 탈까요? 함정이에요. 이건 신호등을 기다려 횡단보도를 건너 150m 떨어진 다른 정류장이에요. 

왜 검색결과는 바로 답을 주지 않나요? 왜 내가 결과를 보고 생각하고 해석해서 답을 찾아야 하나요? 물론 이 앱들은 이런 특정한 맥락을 위한 앱이 아니라 범용적인 맥락의 길찾기 앱인 걸 감안해야 합니다. 

하지만 현재의 목록 위주의 대중교통 특히 버스 길찾기 결과는 사용자의 검색 행태에 적합하지 않습니다. 대중교통 길찾기 사용자를 관찰해보면, 경로를 결정하기 위해 지도로 들어가서 확인하는 경우가 많습니다. 실제 목적지와 도착 정류장이 다르기 때문인데요. 걸리는 시간은 도보 시간으로 가늠할 수 있다고 해도 버스에서 내려 목적지까지 어떤 길로 어떻게 가는지가 사용자의 성향이나 상황에 따라 중요하니까요. 목록에서 지도로 왔다갔다 stacked in time 방식의 정보 표현이라 좋다고 할 수 없습니다. 


지도 기반 길찾기

현재 버스 정류장에 있다는 맥락으로만 한정하면 불필요한 과정을 줄이고 보다 효율적으로 내가 탈 버스를 찾아볼 수 있습니다. 현재 정류장에서 갈 수 있는 버스 노선은 정해져 있으니까요. 

1. 출발 정류장을 선택하면 그 정류장에서 갈 수 있는 노선이 모두 표시됩니다. 

2. 목적지를 지도에서 선택하면 그곳까지 운행하는 버스를 모두 찾아줍니다.

지도에 정류장 별로 그룹핑해서 보여주니까 어디에서 내리는 게 좋은지 바로 확인할 수 있습니다. 

질문은 "어떤 버스를 타는게 가장 좋을까?" 이므로 정보 위계는 버스 번호가 가장 잘 두드러지도록 합니다. 목적지에 빨리 도착하는 게 좋으니까 먼저 목적지에 도착할 버스를 먼저 보여줍니다. 목적지 예정 도착 시각은 현 정류장에의 도착 예정 시간과 이동 시간을 더해서 구합니다.

정보를 나열할 때는 최선의 선택 하나를 추천해 주는 게 인지 비용을 줄여주는데 굉장히 중요합니다. 351,362,401,4318 번 중 먼저 오는 걸 타야지 하고 여러 번호들을 작업 기억 안에서 정류장에 들어오는 버스들을 주의해서 확인 한다고하면 생각만 해도 피곤합니다. 기억해야 할 번호의 수도 많아지고 비교 처리해야 할 작업량도 많아지거든요. 하지만 362가 오는지만 확인하다고 대상이 하나가 되면 훨씬 수월해 집니다.

3. 하지만 그것도 역시 귀찮으니까, 오른쪽 아래 알림 버튼을 누르면 해당 버스가 정류장에 도착 했을 때 알려줍니다.



[참고##정보디자인##]

저장저장


저장저장



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


Trackback 0 Comment 0
Ad Test...
2016.10.31 23:39

버스 승차 알림과 맥락 기반의 implicit interaction

아이를 어린이집에 바래주고 출근하면서부터 지하철 대신 버스를 탑니다. 지하철에 비해 버스를 타면서는 신경 쓸 일이 많아졌습니다. 버스를 타면서 경험했던 불편과 문제 해결을 위한 디자인 과정을 공유합니다.


버스 기다리는 것도 일이다

버스는 정류장에서 버스 기다리는 것 자체가 힘든 ‘일’ 입니다. 지하철은 플랫폼에 열차가 들어 오면 아무 생각 없이 타면 됐거든요. 하지만 버스는 정류장에 정차하는 버스가 내가 탈 버스인지 아닌지 매번 번호를 확인하고 판단해야 합니다. 한적한 정류장에서는 별 일 아니지요. 그런데 제가 타는 정류장은 26개의 노선 버스가 정차하는 중앙차로 정류장입니다. 정말 끊임 없이 버스가 들어오고 나갑니다. 버스가 몰려 버스들이 꼬리를 물고 늘어서면 쏟아져 내린 인파로 금새 혼잡해집니다. 뒷편에 정차한 버스의 번호같은건 보이지 않습니다. 





그런데 뒷편에서 한번 정차해서 승객을 내리고 태운 버스는 운행시간에 좇겨 정류장 앞에서는 정차하지 않고 가버리는 경우가 많습니다. 잠깐 딴 생각하는 사이, 한참을 기다리던 버스가 눈 앞을 그냥 지나쳐가는 경험을 하게 되면 정신이 황폐해집니다. 저 꼬리 뒤에 내가 탈 버스가 온게 아닌지 한시도 주의와 긴장을 놓을 수 없게 됩니다.


버스를 기다리는 건 아무것도 안하고 가만히 있는 것 같지만 뇌를 계속 경계 상태로 두어야 합니다. 인지 비용이 크진 않지만 빈도가 높다 보니 피곤합니다.



주인님, 버스가 지금 도착했습니다

버스앱으로 도착 시간을 미리 알면 긴장을 풀고 뇌를 좀 쉬게 할 수 있습니다. 하지만 시간을 안다고 버스를 놓치지 않는 건 아닙니다. 뇌에 타이머가 달린 것도 아니고 여유가 있으니 딴짓 좀 하게되고, 그러면 버스가 눈앞을 스쳐지납니다. 그래서 버스가 많이 몰리는 중앙차로 같은 곳에는 언제쯤 버스가 오는지보다 버스가 바로 지금 도착했다고 알려주는 알림이 절실합니다. 이런 필요를 만족시켜주는 앱이 없어 직접 만들기로 했습니다.


우선 간단히 도착시간에 맞춰 타이머로 알려주는 방법을 생각할 수 있습니다. 하지만 예상 도착 시간이 교통상황에 따라 빠르거나 느려질 수 있습니다. 버스 떠나고 알려주면 망한겁니다. 그렇다고 너무 일찍 알려주면 또 딴짓합니다.


무식하지만 실시간으로 도착시간을 재확인할 수 밖에 없습니다. 수 초 간격으로 새로 고침하는 건 좀 너무하니 예상 도착 시간의 절반정도가 지났을때 현 위치와 도착 시간을 재확인합니다. 예상 도착 시간을 계속 새로 고침하여 버스가 5초 안에 도착하거나 10m 안에 와 있으면 알려줍니다.


하지만 버스 위치 정보가 실시간으로 업데이트 되지 않아서 제자리에 멈춰있는 것처럼 보일때가 있습니다. 버스는 이미 정류장에 도착했는데 오지 않는 알림은 쓸모가 없습니다. 실시간 위치의 동기가 되지 않을때에도 알림의 신뢰도를 높이는 방법이 필요합니다. 버스 위치가 이전과 같으면 정보가 업데이트 되지 않은 것으로 간주하여 기존 타이머를 유지하고 다를 경우만 타이머를 새로 세팅하도록 하는 방법으로 해결이 가능합니다.


폰에서 이런 반복 작업을 하는건 적합하지 않으니 폰에서 시작 요청을 하면 서버에서 버스 도착을 주기적으로 확인하게 합니다. 서버에서 폰으로 다시 알려주려면 push 서비스가 필요한데, 무료로 push 알림 API를 제공하는 pushbullet 앱을 사용했습니다.


주인님 버스타요.


간단히 다시 설명하면, 도착 시간을 계속 새로 고침하면서 버스가 바로 앞에 왔을때 알려주는 비서인 셈입니다. 작년부터 일년정도 실 사용 중인데 매우 유용합니다. 이전의 비문명화된 삶으로 돌아갈 수가 없어요.


카카오 버스에 이전 정류장에 도착하면 알림을 주는 기능이 생겼습니다. 알림을 보고 지금쯤 집에서 나가면 되겠구나 하고 많이들 유용하게 사용하고 있다고 합니다. 저같은 사람들을 위해 바로 승차 알림도 제공되면 좋겠습니다.



위치-시간 맥락을 이용한 버스 도착 시간 자동 확인


퇴근하는 길에 버스를 한번 갈아탑니다. 지선 버스를 타거나 마을버스를 타는 두가지 선택이 있는데요. 그냥 먼저 오는 버스를 타면 좋겠지만 정류장이 다릅니다. 횡단보도를 건너고 좌우로 서로 300m정도 떨어져 있어서 신호가 바뀌기 전에 미리 뭘 탈지 결정해야 합니다. 고민없이 조금이나마 가까운 정류장으로 가는게 몸도 마음도 편합니다. 하지만 다른 버스는 바로 탈 수 있었는데 정체로 10분, 15분 기다리게 되면 후회됩니다. 그래서 매번 두개의 버스 도착 시간을 확인합니다.


버스앱의 즐겨찾기나 위젯을 이용하면 도착시간을 그나마 수월하게 확인 할 수 있습니다. 하지만 이것도 매번 전화를 꺼내 화면을 켜고 앱을 실행시켜(또는 위젯을) 확인하는 과정이 번거럽고 귀찮습니다. 


꼭 버튼을 누르거나 하는 명시적인 입력이 아니라도 사용자가 특정 시간에 특정 장소로 이동했다는 행위자체가 트리거가 될 수 있습니다. 기기의 센서가 맥락을 확인하고 사용자의 명령을 대신합니다. 스마트폰의 위치 정보로 geofence를 활용할 수 있는데요. 안드로이드에서는 tasker, 아이폰에서는 locative 앱이 이런 기능을 제공합니다. 지도상에 존을 지정하고 그 영역 안에 들어가거나 나오면 특정 명령을 수행하도록 webhook을 걸 수 있습니다. 정류장 근처에 도착하면 내가 탈 버스들의 도착시간을 확인해서 알려주도록 했습니다.


locative를 이용한 geofence



서버에서 두 버스의 도착 시간을 확인하고 push로 폰에 알려줍니다. 정류장에 내리면 갈아탈 버스들이 언제 도착하는지 알림이 옵니다. 폰에 알림이 오면 스마트워치에도 같이 표시됩니다. 전 pebble워치를 쓰는데, 휴대폰을 꺼낼 필요 없이 손목을 들어 어느 버스가 먼저 도착하는지 확인하고 어느 정류장에서 탈지 결정합니다. 두 버스의 도착 시간을 비교하는 것도 인지 비용이 생기니 먼저 도착하는 버스를 앞에 보여줍니다. 아무것도 안하지만 더 격렬하게 아무것도 안하고 싶거든요. 물론 앞의 승차 알림도 함께 실행되어 버스가 정류장에 도착하면 다시 알려줍니다. 


geofence를 이용한 버스도착시간 자동 알림



1. 기다리는 것은 아무 것도 안하는 것 같지만 우리의 주의라는 인지 비용을 소비하는 활동입니다. 기다리는 시간 자체를 바꾸기는 어렵지만 인지 비용을 줄여주는 것으로 기다림의 불편함을 많이 해소해 줄 수 있습니다.


2. 똘똘한 비서는 주인의 명시적인 명령이 아니라 맥락을 살펴 능동적으로 일을 처리하는 비서입니다. 요즘 유행하는 IoT도 결국 센서와 AI가 맥락을 이해하여 implicit interaction을 수행하는 방향으로 발전하고 있습니다.


다음에는 이런 no UI의 근간이 되는 지도 기반의 버스 앱을 소개해 드리겠습니다.



[참고##리디자인##]


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


Trackback 0 Comment 5
Ad Test...
2016.06.16 07:50

트위터 퍼소나 데모 페이지

지난번 트위터 사용자 유형 - 데이타 기반 퍼소나 글에서 로그 데이타를 이용하여 사용자 유형을 시각화하는 방식을 소개했습니다. 사용해보고 싶어하시는 분들의 요청이 있어 데모 페이지를 만들었습니다.

http://lab.pxd.co.kr/twitterpersonas/

트위터 계정 아이디를 넣으면 최근 200개의 트윗을 시간축 상에 트윗의 특성을 시각화하여 보여줍니다.

날짜와 시간은 사용자의 거주 위치에 따라 보정하여 표시하고 있어서 정보를 정확하게 입력하지 않은 경우 시간이 밀려있을 수 있습니다. 

 

  • 우선 트윗을 자기가 직접 작성한 것, 리트윗한것, 인용 RT, 멘션 네가지로 색깔 별로 나뉘었습니다.

  • 페이스북에서 작성한건 진한 파랑, 인스타그램에서 작성한 건 노랑으로 표시됩니다.

  • PC에서 작성한 것은 테두리로 표시합니다.  

  • 이미지 첨부나 비디오 첨부는 노랑,빨강의 작은 네모가 붙습니다.

  • 해쉬태그는 #, url 링크는 _ 텍스트가 추가됩니다.

  • 직접 작성한 트윗 중 리트윗된 비율(평균 리트윗 횟수), 좋아요 비율(평균 좋아요 횟수) 를 표시합니다.


[참고##퍼소나##]


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


Trackback 0 Comment 2
Ad Test...
2016.05.19 07:50

데이타 기반 퍼소나 - 트루밸런스

트루밸런스는 인도를 기반으로 선불폰 잔액 조회를 중심으로 요금제 큐레이팅, 즉각 충전 플랫폼으로 확장하고 있는 핀테크 서비스입니다. pxd는 디자인을 통해 투자 참여를 하고 있습니다.
과제의 초기에 사용자 이해를 위해 데이타 분석했던 과정을 소개합니다.


Rapid Personas

우리와는 다르게 동남아시아에서는 선불로 충전하여 통화와 데이타를 사용하는 경우가 많다고 합니다.
선불로 충전한 통화 잔액이나 데이타의 잔량을 확인하기 위해서 quick codes(USSD)라고 하는 sms와 유사한 문자기반의 잔액 조회 기능을 이용하고 있습니다. 통화 상품, 시간대, 통화상대, 프로모션에 따라 통화 요율이 달라지기 때문에 단말 단에서 잔액을 계산하는 것이 사실상 어렵기 때문에 서버에서 계산된 잔액을 요청하고 확인할 수 밖에 없다고 합니다.

USSD 프로토콜을 이용해 특정 번호로 전화를 걸면 서버에서 잔액 정보를 전송하고,그것을 팝업으로 표시하는 형태입니다. 앱을 통한 조회를 제공하기도 하지만 데이타 사용 이슈가 있어서 거의 사용되고 있지 않다고 합니다. 통화가 얼마나 남았는지, 데이타를 얼마나 사용했는지 확인하는 것이 꼭 필요하고 빈번하게 일어나는 작업임에도 사용은 매우 불편하게 되어있습니다. 트루밸런스는 이런 번거러운 작업을 간편하게 확인 할 수 있도록 하는 것을 우선 MVP로 잡아 개발을 시작했습니다.
USSD를 통한 잔액 조회. 잔액이나 데이타 잔량을 팝업으로 알려준다.

초기에는 선불제에 대한 경험이나 지식이 별로 없어 인도 현지의 직원들을 통해 얻은 정보로 선불폰 사용자의 사용 행태를 가늠해 볼 수 밖에 없었습니다.

선불폰 사용자 (Rapid Personas)

  • 통신사별 이용상품에 따라 음성통화료와 DATA 이용요금의 차이가 있다. (Context)
  • 가까운 점포나 길거리 등에서 현금을 지불하여 Top up을 한다. (Context)
  • 지역별로 통신사의 신호세기의 차이가 있다. (Context)
  • 2개의 유심을 위치(집과 직장)따라 구분해서 사용한다. (Behavior)
  • 전화를 걸기전 매번 사용할 유심을 선택한다. (Behavior)
  • 일주일에 평균 2-3회 Top up을 한다. (Behavior)
  • 잔액을 미리확인하고 다 떨어지기 전 Top up을 해 둔다. (Attitude)
  • 요금을 절약하기 위해 통신사에서 제공되는 혜택에 따라 유심을 바뀌가면서 사용한다. (Attitude)
  • 데이터를 쓴 직후 어디에 얼마나 사용했는지 궁금하다. (Attitude)
  • 사용후 평소보다 내가 많이 쓰지는 않았는지 걱정이 된다. (Attitude)


로그 시각화

트루밸런스는 초기 베타버전에서부터 사용자의 동의를 얻고 로그를 수집하는 기능을 넣어 어떤 사용자들이 이 앱을 사용하는지, 어떤 패턴으로 사용하는지를 실제 사용자들로 부터 데이타를 얻어 디자인에 활용하였습니다.


로그는 통화 종료시 또는 사용자가 명시적으로 잔액 조회를 요청했을때의 잔액값들로 구성되어 있습니다. 개별적인 잔액 데이타는 사용자를 이해하는데 별 도움이 되지 못합니다. 하지만 이 데이타를 시계열로 모아 적분하듯이 재구성하면 사용자의 충전, 사용 패턴이 드러납니다. 얼만큼의 주기로 어느 정도 금액을 충전하는지를 알 수 있습니다.
잔액의 로그 시각화는 구글 차트 api를 활용하였습니다.

개별 사용자의 사용 패턴을 뽑아내면서 새로이 사용일, 충전주기, 평균 충전액, 잔액 조회 주기 등의 값들을 계산하여 DB에 추가하고 이런 개별 특성을 시각적으로 구분하여 나타내도록 했습니다. 최근 며칠 이상 로그가 없는 단말은 앱을 삭제한 것으로 추정하여 사용자들을 구분했습니다.

이런 특성들에 따라 DB query를 통해 살펴보기 원하는 특성의 사용자들을 골라내고 개별 잔액 그래프를 펼쳐놓아 비슷한 유형을 찾고 사용 패턴(앱의 충성 사용자, 앱 삭제)에 영향을 주는 요인을 확인해 보았습니다.



일반적으로 한번 충전 금액이 많은 경우 충전 주기도 길고 여유가 있으니 잔액을 조회하는 빈도로 줄어들 것으로 예상할 수 있습니다. 하지만 잔액 조회 빈도는 충전 금액과의 상관 관계보다 사용자의 태도의 영향이 큰 것 같습니다. 트루밸런스는 그런 사용자들을 위해 조회하는 행위 자체가 즐거움을 주도록 설계하였습니다.



누가 어디에서 사용하나?

이후 마케팅을 위해 사용자들이 주로 어디에서 앱을 사용하는지를 시각화했습니다.
처음 한 곳에 이상하게 너무 많은 사용자가 몰려있어서 놀랐는데 한 사용자의 여러 로그를 그대로 다 표시하다 보니 생긴 문제였습니다. 한 구역에서 한 사용자는 하나로 묶어서 표시하는 식으로 수정하였습니다.
평균 충전금액에 따라 버블의 크기를 달리했었는데 큰 버블이 많이 모이는 지역들이 있었는데요. 아마 부자 동네가 아닐까 싶기도 하네요.

기존에는 정성적 사용자 조사와 정량적 조사를 서로 다른 영역이라고 보고 정성적 사용자 조사에 집중하고 있었는데요. 사용자 데이타를 사용자 전체의 통계적인 대표값을 얻는데 사용하기보다 개별 사용자의 꼼꼼한 journaling이라고 보고, 정성적 조사의 근거 자료로 사용하면서 실제 사용자를 이해하는데 많은 도움을 얻고 있습니다.

[참고##퍼소나##]



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


Trackback 0 Comment 0
Ad Test...
2016.05.04 07:50

아이와 함께 만드는 한글 공부 키보드

어린이집을 다니는 둘째 딸아이가 한글에 흥미를 보이길래, 한글의 자소와 구성 원리를 놀이처럼 배울 수 있는 앱을 만들었습니다. 아이가 사용하는 것을 관찰하고 새롭게 발견한 점을 디자인에 반영하는 과정을 반복했습니다. 아이가 한글을 배우는 동안 저는 더 많은 걸 배웠습니다. 1년 동안 아이와 함께 한글 공부 키보드를 만들며 배운 것을 공유합니다.


우리 아이는 언제 한글을 배워야 할까?

저는 너무 일찍부터 아이들에게 한글을 가르치려고 하는 게 마뜩잖아 보입니다. 예전에는 어린이집과 유치원의 교육 과정이 달라서 유치원에서는 좀 더 일찍 한글을 가르쳤다고 하는데요. 이제는 누리과정으로 일원화되면서 아이 나이에 따른 학습 발달 단계에 맞춰서, 교과 위주의 인지 학습보다는 놀이 위주로 호기심과 표현 능력, 사회성 등을 키워주는 데 초점을 맞추었다고 합니다. 이런 교육 방침에 공감하기에 될 수 있으면 아이가 흥미를 갖기 전에 남들이 다 한다고 조급하게 미리 가르치려고 하지 않았습니다. 방치하고 있습니다. :)
굳이 한글을 가르치지 않아도 어린이집에서 공동 생활을 하다 보면 자기 이름 정도는 읽게(분별해 내게) 되더라고요. 신발장이나 서랍장, 메모장에 이름을 붙여 놓아 일상에서 반복적으로 자기 이름을 확인해야 하는 상황에 놓이니 자연스레 익히게 되나 봅니다. 자기 이름을 쓰고(따라 그리고) 몇몇 친한 친구의 이름도 읽을 수 있게 되면 뿌듯해합니다.


상상나라 미래명함

아이들과 서울시에서 운영하는 놀이 체험 전시 공간인 상상나라에 자주 놀러 갔었는데요. 아이가 그중 미래명함을 좋아해 갈 때마다 몇 번씩 줄을 서가며 새로운 명함을 뽑았습니다.

출처 : 상상나라 홈페이지
스크린을 터치해 장래 희망 직업을 고르고 이름을 입력하면 종이에 명함을 출력해주는데요. 상상나라 안에서 몇 안 되는 디지털 설치물이라 저도 관심 있게 살펴보았습니다. 스마트폰이나 태블릿을 많이 접해서인지 어린 아이들도 사용하는데 별 어려움이 없어보였습니다. 다만 이름을 입력할때는 부모님이 도와주는데요. 한글을 모르는 어린 아이들도 엄마 아빠가 대신 입력해주려고 하면 자기가 직접 하겠다고 어떤 자판을 누를지만 가리켜 달라는 경우가 많았습니다. 한 자 한 자 자판을 눌러서 화면에 자기 이름이 만들어지는 걸 흥미로워합니다. 저에게는 아이들이 터치 자판으로 이름 입력하는 것도 놀이처럼 즐기는 모습이 흥미로웠습니다. 어른들은 사용자 등록이나 인증한다고 이름 입력하라면 바로 막 귀찮아지잖아요.


한글 도깨비불 현상

그런데 우리 애가 자꾸만 잘못 썼다고 지우고 다시 쓰길 반복하더라고요. 가만 보니 두벌식 자판이라 도깨비불 현상이 생기는 게 문제였습니다. 아이 이름이 '한가인'이라고 하면 '한가' 다음에 'ㅇ'을 눌렀는데 '한강'이라고 화면에 나오니 잘 못한 줄 알고 지우는 거였습니다.


두벌식 도깨비불 현상. 


어른들이야 이런 현상이 익숙하니 잘못이 아니라는 것도 알고 타자가 빠르니 신경 쓰지 않고 넘어갑니다. 하지만 아이는 또박또박 자판 한번 누르고 글자 확인하기를 반복하다 예상치 않은 글자가 나오니 자기가 실수 했다고 생각했나 봅니다.
엄마는 원래 그런거니 그냥 계속 쓰라고 알려줬지만, 제게는 UI에 문제가 있어 보였습니다. 시스템의 문제를 사용자가 잘못했다고 자신을 탓하게 하는 건 나쁜 UI거든요.
누구나 처음에는 이상하다고 잘못됐다고 생각하는 것들도 매일 반복되다 보면 무뎌지고 익숙해지면서 그대로 받아들이게 됩니다. 경험 많은 어른은 원래 그런 거니 어쩔 수 없는 거라고, 익숙해지면 괜찮다고, 괜히 힘들이지 말고 네가 거기에 맞추라고 가르칩니다.

세상의 다른 많은 문제들을 모두 해결해 줄 수는 없지만 한글 타자의 도깨비불 정도는 해결해 줄 수 있을 것 같았습니다. 저는 세벌식을 쓰고 있거든요. 세벌식에서는 도깨비불이 어쩔 수 없는 문제가 아닙니다.
한글의 도깨비불 현상은 초성과 종성을 자음 한 벌만 사용하여 입력 오토마타가 사용자의 의도를 구분할 수 없어 기계적으로 다음 자음을 종성으로 우선 처리하여 생기는 문제입니다. 초성과 종성 자판이 따로 있는 세벌식에서는 발생하지 않습니다.


세벌식 프로토타입

아이가 한글 키보드로 한글이 만들어지는 걸 흥미로워하고 한글에도 관심을 보이니 한글 공부를 위한 키보드를 만들어보면 좋겠다는 생각이 들었습니다. 하지만 이런 도깨비불 현상이 처음 한글을 배우는 데에는 심각한 방해가 될 수 있으니 이런 문제가 없는 키보드를 만들어보기로 했습니다. 그래서 바로 세벌식으로 된 키보드를 스케치했습니다.



세벌식 터치 키보드 스케치. 자음, 모음 배열


기존 한글 오토마타 소스를 이용해 세벌식 터치 자판 프로토타입을 만들어 아이에게 글씨가 써지는 걸 보여줬습니다. 뭔가 누르면 글씨가 생겨나니 재밌어합니다. 입력필드에 그냥 타이핑이 되는게 아니라 자판을 누르면 자소가 뿅 날아가는 애니메이션을 추가했습니다. 자판에 표시된 자소가 이전 자소들과 조합하여 글자가 된다는 것을 직접적으로 보여주려고요. 관심을 가지게 하는건 성공했습니다. 도깨비불도 안생기고요.


도깨비불 현상이 없는 세벌식 터치 키보드 초기 프로토타입

대신 아이가 초성 대신 종성을 먼저 누르는 경우가 있었습니다. 그래서 우선 종성을 먼저 누르면 입력이 안 되도록 막는 규칙을 추가했습니다. 자판을 모아쓰기처럼 초성 중성 종성 위치에 모아 두고 위의 초성 자판부터 순서대로 눌러야 한다고 가르쳐주었습니다.
빈도는 줄었지만 그래도 아이가 종성 키를 먼저 누르거나 종성 키 대신 초성 키를 잘못 누르는게 없어지진 않았습니다. 아니라고 다시 규칙을 설명해주다 갑자기 깨달았습니다. 아이가 잘 못 하는 게 아니라 디자인이 잘 못되었다는 걸요. 사용자에게 열심히 사용 방법을 설명하고 있다는 건 디자인이 나쁘다는 방증입니다. 직접 써 붙인 사용 설명서가 덕지덕지 붙어있는 무인 정산기들을 보면 알 수 있지요.


진짜 문제가 무엇인가?

다시 원점으로 돌아왔습니다. 한글의 원리를 가르치는 한글 키보드를 만들려 하는데, 현재의 두벌식 자판은 도깨비불 현상이 생겨서 아이를 혼란스럽게 합니다. 대안으로 세벌식으로 초성과 종성을 나누면 도깨비불은 해결되지만 똑같은 자음이 두 벌인 것이 아이를 오히려 헷갈리게 합니다. 어떻게 해야 할까요?

해결은 이미 있었습니다. 제가 두벌식과 세벌식이라는 프레임에 갇혀 있던 게 문제였지요.
어릴 적 가지고 놀던 한글 자석 글자 놀이에는 도깨비불이 없었거든요. 키보드가 아니라 글자 블록이라고 개념을 바꿨습니다. 글자를 끌어놓아 자음이 받침 자리에 올지 다음 글자의 첫머리에 올지 구분하도록 했습니다. 끌어 놓기로 방식을 바꾸니 조각 퍼즐 맞추기 게임에서 익숙한 형태라 아이들이 더 재밌어합니다.
문제 해결!


한글 끌어놓기를 통한 자음의 종성, 초성 구분 오토마타


나쁜 디자인은 문제가 무엇인지 제대로 이해하지 못한 상태에서 무턱대고 해결부터 하려 한 경우일 때가 많습니다. 제가 도깨비불이 생기는 것을 보고 두벌식이 문제라고 생각한것 처럼요. 좋은 디자인(문제 해결)은 진짜 문제가 무엇인지 명확히 정의하는 것에서부터 시작되어야 합니다. 문제가 무엇인지 명확하면 대부분의 해결은 다른 도메인의 해결을 가져올 수 있습니다. Good Artists Copy, Great Artists Steal.


기역니은 보다 한글 구성 원리를 먼저 배우자

키보드가 동작하게 만들고 나서 바로 단어를 먼저 보여주고 따라 쓰는 기능을 만들어줬습니다. 뭘 쓸지 알려주기 귀찮아서요. :) 조각 퍼즐을 맞추는 것처럼 맞게 따라 쓰면 박수 소리를 내며 잘 맞췄다는 피드백을 줘서 아이에게 성취동기를 부여해줬습니다.
아이들이 흥미를 느끼게 하는 데는 성공이었습니다. 공부보다는 조각 퍼즐 놀이로 생각해서인지 시키지 않아도 첫째와 둘째가 서로 다퉈가며 했거든요. 오히려 너무 많이 하려고 해서 금지해야 할 정도였습니다.

아이가 이걸 공부가 아니라 게임이라고 생각하게 된 큰 이유는 자소를 외우기보다 스스로 찾도록 한 데 있는 것 같습니다. Recognition rather than Recall 이라는 사용성의 원리처럼 키보드 자판을 보고 자소를 찾는게 외워서 회상하는 것보다 쉽다는 것도 있겠지만 그보다는 스스로 발견해내는 즐거움을 주기 때문이라고 생각합니다.


유아용 한글 공부 교재는 대부분 ㄱㄴㄷ을 먼저 가르칩니다. 자음을 배우고 나면 ㅏㅑㅓㅕ 모음을 배우고요. 바로 써먹지 못하는 자음 모음 24자를 배우고 시작하려면 재미도 없고 쉬 지치게 됩니다. 무엇보다 공부가 재미없다는 걸 먼저 배우고 거부감을 가지게 됩니다.
저도 처음 한글 키보드를 만들 때는 자판을 보고 한글 자소를 가르치는데 도움이 되지 않을까 생각했는데요. 그보다는 한글 구성 원리를 체득하는 게 보다 중요하다는 걸 알게 되었습니다. 완성된 글자(음절)를 보고 스스로 자소를 분리하고 그것들이 조합되어 하나의 글자가 만들어진다는 규칙을 이해하는 게 한글을 배우는 데 더 도움이 되었습니다. 기역니은을 몰라도 대충 이런 형태의 조각(자소)들을 순서대로 모아쓰면 하나의 글자(음절)가 만들어진다는 원리만 이해해도 성공이라고 생각했습니다.
퍼즐의 규칙(한글 모아쓰기)을 익히며 놀다 보면 빈번한 퍼즐 조각(자소)들은 자연스레 익히게 됩니다. 

공부한다고 하면 의레 바로 외우는 것을 생각하지만 바로 외우지 못하더라도 눈에 익은 조각이다 보니 나중에 한글 교재를 볼 때 거부감이 확연히 줄어들었습니다. 억지로 가르치지 않고 스스로 흥미를 느끼고 많이 접해서 우선 익숙해지는 것이 아이들이 배우는 데 보다 효과적입니다.



모아쓰기 순서

아이가 처음 자기 이름을 쓰는 걸 보면 글자를 쓴다기보다 그림을 따라 그리는 수준입니다. 눈에 보이는대로 가까운 것부터 그립니다. '한'을 쓸 때 'ㅎ'을 쓰고 아래쪽 받침 'ㄴ'을 그린 다음 'ㅏ' 모음을 옆에 그리는 것을 자주 보았습니다. 
각각의 자소가 모여 글자가 만들어지고 또 그것에 순서가 있다는 규칙을 이해하도록 하도록 자판에 자음과 모음을 다른 색으로 나누어 모아 두었습니다. 자음과 모음이라는 소리 성질이 다른 글자들이 있고 처음에 자음을 먼저 맞추고 그다음은 모음 쪽 조각을 번갈아가며 맞춰야 한다고 설명해 주었습니다. 또 모음 전에 종성을 끌어놓으면 글자가 되돌아가게 해서 순서라는 규칙을 피드백으로 알려주었습니다.

결과적으로 이런 퍼즐 형식이 한글 구성과 모아쓰기 순서를 학습하는 데 효과적이었습니다. 며칠 가지고 놀더니 올바른 조각(자소)을 찾는 시행착오와 순서를 틀리는 실수가 확연히 줄어들어 별문제 없이 글자를 완성할 수 있게 되었습니다. 
이전에 한글 획을 순서대로 따라 쓰기 연습하는 유아용 한글 공부 앱들도 사용해봤는데 별 효과가 없었거든요. 자소를 구분하기보다 따라 그리는 연습만 되어서 처음 한글을 배우는 데 적합한 방법은 아닌 것 같았습니다.


처음 한글을 배우는 유아를 위한 한글 글꼴

아이가 '한글'을 쓸 때 '한'까지는 잘했는데 '글'을 입력 차례에서 자판을 한참 바라보더니 'ㄷ'을 골랐습니다. 아니, 우리 애가 정말 기역도 모르는구나 충격을 받았습니다. 그 후에도 전혀 다르게 생긴 틀린 글자를 고르는 경우가 있어서 한글을 배우려면 역시 남들처럼 기역니은 부터 가르쳐야하는구나 생각했습니다.
하지만 그런 어처구니없는 행동을 관찰하다 보니 패턴이 보였습니다. ㄱㄴㄷ 자소의 전체 세트를 알지 못하니 시각적으로 이어진 덩어리의 획들이 하나의 자소라고 인지하는 것이었습니다. 사용한 폰트에서는 '그' 가 한 덩어리로 붙어 보였던 거죠. 한글을 읽을 줄 알면 'ㄱ'과 'ㅡ'가 합쳐진 거로 나누어 보는 게 당연하지만, 아이에게는 하나의 자소로 보였나 봅니다.
그래도 획 방향이 전혀 다르잖아! 생각해보니 '그'를 'ㄷ' 으로 본 이유는 아이가 한글 자석 교구를 가지고 놀았던 경험이 있기 때문이었습니다. 글자를 종이에 써서 배운 게 아니라 자소를 자유롭게 돌려서 붙일 수 있었으니까 둘은 같은 모양이었던거죠. 기호 구분을 못하는게 아니라 오히려 공간 지각 능력이 뛰어난 거였습니다. RtA라면이 외국에서 인기 인것처럼요. 'ㅎ'의 획이 세로로 반듯한 글꼴을 사용했을 땐 'ㅗㅇ'으로 자소를 분리하는 경우도 있었습니다. 


아이의 눈으로 보이는 자소 분리


외국에서 인기 있는 RtA라면

자소가 붙어 있는 건 잘 만든 글꼴이기 때문입니다. 영어에 ligature 폰트가 따로 있듯이 자소 사이에 어설프게 작은 여백이 있으면 글자가 복잡해 보이니 여백이 없도록 한글자씩 다듬어 준 것입니다.
처음 한글을 배울때 자소를 좀 더 쉽게 구분해서 인지할 수 있도록 자소가 붙어있지 않고 너무 반듯하지 않은 손글씨 모양이면서 자소들이 큼직한 형태의 폰트를 찾아서 바꿔줬습니다. 글꼴을 바꾸어 테스트하니 이런 실수가 실제로 줄어들었습니다.

요즘 인터넷에서는 이렇게 한글 자소 형태의 유사성을 가지고 장난하는 게 하나의 유행인가 봅니다. 영어의 경우에는 leet 이라고 w1n5t0n M1k3y 같은 표기가 예전부터 유행했는데 우리나라에서는 야민정음이라고 하더라고요. 이런 글자들 중에 OCR이 잘 못 읽은 글자들도 있는데요. 기계가 오류 없이 읽기 위해 OCR 전용 서체를 만들었던 것 처럼 아이가 처음 한글을 쉽게 배우는데 효과적인 한글 서체도 고민해 보는 것이 필요할 것 같습니다.


자소 이름과 음절, 단어 읽어주기

글자 퍼즐 맞추기를 하면서 자소 형태뿐 아니라 이름을 배울 수 있도록 자소를 끌어서 움직일 때 기역, 니은 하고 이름을 읽어 주도록 하였습니다. 자소를 끌어놓아 음절이 만들어지면 그 글자도 읽어주고 단어가 완성되면 단어도 읽어주었습니다.
바로 학습 효과를 보이지는 않지만, 글자와 이름을 반복적으로 보고 들은 것이 나중에 책에서 글자를 배울때 효과가 있었습니다.

글자를 읽는데는 webkit 엔진에 포함된 한글 TTS를 사용했습니다. 한글 공부를 위해 충분히 괜찮은 발음을 들려주었으나 특정한 단음절의 발음에 버그가 있습니다. ㄱ ㄷ ㅂ ㅈ이 단모음과 연결되어 한음절이 되면 ㅋ ㅌ ㅍ ㅊ에 가까운 파열음으로 발음됩니다. 받침이 붙거나 2음절 이상이 되면 정상적으로 발음됩니다. 애플에 버그 리포트를 넣었는데 몇 년 동안 고쳐지지 않고 있습니다. 안드로이드에서는 별도의 TTS 엔진을 사용하는 것 같은데도 비슷한 오류가 있습니다. 잘 아시는 분이 있으면 설명 부탁드립니다.


낱말 이미지

단어가 완성되면 이미지를 보여주도록 했습니다. 유아용 낱말 카드에 글자와 이미지가 있는 것처럼 글자를 읽지 못하고 따라 쓰더라도 그림이 나와서 둘을 연관시킬 수 있도록 했습니다.
꼭 제시된 단어만이 아니라 글자를 완성하는 도중이라도 학습 단어가 나오면 그림이 나오도록 했습니다. "강아지"를 입력하는 도중 "강" 라고만 써도 강 그림이 나오도록이요. 뜻밖의 재미가(serendipity) 학습 기회를 더 만들어 주도록 했습니다.

다만 문제는 이런 이미지를 일일이 지정해주기 귀찮아서 구글 이미지 검색을 이용했는데, 구글의 이미지 검색엔 safesearch 옵션을 켜도 선정적인 이미지가 나옵니다. 영어는 그나마 검열이 되는 것 같은데 한글은 제대로 동작하지 않습니다. 데이타가 적어서인지 구글코리아가 신경을 안쓰는 건지 모르겠습니다. 그렇다고 네이버 이미지 검색을 쓰기엔 원하는 이미지가 잘 찾아지지 않아서 대체하기도 어려워 아쉬웠습니다. 아무 글자나 노출되는걸 막으려고 네이버 사전에 등록된 단어에 대해서만 이미지를 보여주고 또 문제가 되는 단어들은 블랙리스트를 만들어서 관리하도록 했습니다.


한글 자판 배열

처음 세벌식 자판이 한글을 배우는데 실패라는 걸 배우고 나서 자음 모음을 어떻게 배열할지 고민했습니다. 타이핑 연습을 하려는 게 아니니 두벌식자판을 그대로 따라 하는 건 의미가 없으니까요. 두벌식 자판은 자소 빈도에 따라 효율적으로 배열된 것도 아니고 학습이 쉽도록 한 것도 아니거든요.


아이가 한글 자소를 알고 찾는 게 아니라 자판에서 비슷해 보이는 기호를 찾으면서 배워가는 것이라 비슷한 형태의 자소를 모아두어 차이를 비교하면서 선택할 수 있도록 했습니다. 그러다 보니 자연스럽게 한글의 창제 원리와 비슷하게 배열이 되었습니다. 한글이 기본 자형에 획을 추가하는 형태로 만들어졌으니까요.


모음의 경우 두벌식은 기본 모음 10개에 이중모음 중 ㅐㅔㅒㅖ 를 추가한 형태입니다. ㅐㅔ 의 빈도가 높으니 입력 편의를 위해 제공하는 것이겠지만 입력 효율이 아니라 학습이 목적이니 자판을 가급적 간단히해서 복잡해 보이지 않게 하는데 비중을 두었습니다. 또 ㅐㅔ 의 발음 구분이 안되어 맞춤법을 틀리기 쉽기때문에 일부러 ㅏㅣ , ㅓㅣ 로 나눠 입력하면서 한번 더 생각하고 쓰기를 바랐습니다. 양성,음성 모음을 같은 위치에 일관성 있게 배열하여 ㅘ ㅙㅝ ㅞㅢ 같은 이중 모음을 입력할 때 같은 자리에서 글자를 쉽게 찾도록 했습니다. 


한글 학습용 자판 배열



아이가 관심을 가지고 일상에서 자주 접하는 글자가 효과적이다

유아 한글 교재는 주로 동물, 사물, 과일 등의 낱말 카드가 많습니다. 글자를 몰라도 인지할 수 있도록 그림으로 표현하기 수월한 명사 위주로 받침이 적은 쉬운 낱말 위주로 고른 것 같습니다. 저도 처음엔 그런 교재들을 참고하여 기본 단어장을 만들어 보여줬는데요. 아이가 별로 흥미를 보이지 않았습니다.


글자가 쉬운 것부터 보다는 아이가 좋아하고 일상에서 자주 접하는 단어를 보여주는 게 더 효과가 있었습니다. 아이들이 즐겨보던 만화인 바다탐험대의 주인공 바나클, 콰지, 페이소, 옥토넛 이나 라푼젤 공주같은 글자 맞추기에 더 흥미를 가졌습니다. 


우리말에는 잘 쓰이지 않는 ㅋㅌㅍ가 많이 사용되는 외래어라는게 좀 걸렸는데 아이가 관심을 가지는 좋은 낱말을 찾았습니다. 바로 친구들 이름이었습니다. 가장 친한 친구 이름부터 선생님 이름으로 공부를 했는데요. 이름을 입력하면 친구 얼굴이 나오도록 해주니 아주 좋아했습니다. 이름에 공통된 글자들이 있어서 아이가 아는 글자가 나오면 좋아하고 글자가 반복되니 수월하게 배울 수 있었습니다. 



아이가 흥미를 느끼고 스스로 배울 수 있게 해주세요.

이걸 만든 게 3년 전이었는데요. 첫째는 만 다섯, 둘째가 만 세 살 이었습니다. 결과적으로 첫째 남자아이는 한글 안 배우고 놀다가 초등학교 입학하기 전에 엄마한테 혼나면서 힘들게 한글을 배웠고 둘째 여자 아이는 이 앱 덕분인지 오빠 공부하던 한글책 같이 보면서 수월하게 한글을 빨리 배웠습니다. 샘플이 적어서 앱의 효과인지 사용자 성향의 차이인지 검증이 어렵습니다. :) 

그래도 도움이 되었던 점을 정리하면 이렇습니다.


1. 한글을 억지로 가르치려고 하기보다 글자에 관심을 가지도록 환경을 만들어 주는 게 중요합니다.

2. 쉬운 글자보다 어렵더라도 아이가 흥미를 느끼고 일상에서 자주 접하는 글자 위주로 배우도록 하는 게 실용적입니다.

3. 한글 자소를 외우게 하는 것보다 한글 구성 원리를 우선 배우도록 하는 게 효율적입니다. 

4. 자소나 한글 규칙을 스스로 발견하는 재미를 주어 글자에 흥미를 가지도록 합니다.

5. 아이를 가르치기 보다 아이를 관찰하면서 내가 배울 것 을 찾아 보세요.


한글을 배우게 하는 것보다 한글을 배우면 즐겁다는 걸 알게 해주는게 더 중요합니다. 외국 여행 갈때면 그 나라 말을 배우지는 못해도 안녕하세요. 고맙습니다. 정도의 현지어는 꼭 외워서 가려고 합니다. 그러면 여행이 더 즐거워지거든요. 그 정도 느낌으로 시켜서가 아니라 아이들이 한글을 알게 되었을 때의 재미를 느끼며 배우면 좋겠습니다.







[참고##리디자인##]




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


Trackback 0 Comment 12
Ad Test...
2016.04.18 08:16

트위터 사용자 유형 - 데이타 기반 퍼소나


데이타 기반 퍼소나


요즘 Lean UX 같은 사용자 데이타에 기반을 둔 디자인 방법이 대세입니다. 디자이너의 경험과 감이 아니라 사용자 행동으로 나타난 실제 피드백을 근거로 하므로 보다 신뢰를 얻고 있습니다. 하지만 여기에서의 사용자는 다양한 특성을 가진 개개인으로서의 사용자라기보다는 전체로서 통계화된 대상입니다. 사용자를 이해하고 문제가 무엇인지 찾는 과정보다는 문제의 해결을 실험해보는 과정에서 주로 사용되는 방법입니다.


좋은 디자인을 위해서는 우선 누구를 대상으로 하는지, 어떤 니즈를 해결해주려고 하는지 문제를 명확히 하는 것이 중요합니다. 그래서 사용자를 모델링 하여 대상을 명확히 하는 퍼소나 방법이 이제 UI/UX 디자인에서 거의 필수적인 과정으로 자리잡았습니다.
하지만 퍼소나가 실제 사용자의 데이타와는 상충될 수도 있다거나 같은 사용자 데이타를 가지고도 디자이너에 따라 다른 퍼소나가 나올 수 있다는 방법적인 약점에 대한 비판들도 있어왔습니다. 이는 사용자에 대한 정보 자체가 정성적인 조사 방법에 의존하고있고 도출 과정에서 주관적인 편향이 작용하는 것을 배제할 수 없기때문입니다.
이를 보완하기 위해서는 서비스 운영에서 수집되는 실제 사용자 데이타를 이용하는 것이 한 방법이 될 수 있습니다. pxd에서는 로그 데이타 기반 퍼소나를 기존 퍼소나를 보완하는 방법으로 과제에 적용하면서 좋은 결과를 얻고 있습니다.

트위터의 공개된 사용자 기록(트윗)을 이용해 사용자의 행태를 시각화하고 유형화하는 방법을 살펴보겠습니다.


로그 데이타를 통한 사용자 행태 재구성


사용자 유형을 만드는 데는 데이타 분석에서 주로 사용하는 전체 사용자의 정량적 지표가 아닌 사용자 개개인의 로그 데이타를 사용합니다. 로그 데이타로 남겨진 사용자 흔적을 재구성하여 사용 행태를 관찰하는데 활용합니다.

최근 온라인, 모바일 서비스들은 현장에서 사용자 행태를 직접 관찰하는 것이 어려워졌습니다. 사용 맥락도 하루 중 수시로, 도처에서, 걷거나 심지어 운전 중에도, 일어나자마자, 잠들기 전에, 화장실 같은 극히 개인적인 공간에서 사용이 일어납니다. 작은 화면에서 짧은 시간에 빠르게 작업이 이뤄져서 재현하더라도 무슨 일이 벌어졌는지 알기 어렵습니다. 경우에 따라 다이어리 스터디 같은 저널링을 통해 유용한 실마리를 얻기도 하지만 한계가 있었습니다. 로그 데이타는 사용자의 행태를 가장 성실하고 꼼꼼하게 기록한 다이어리 역할을 합니다.

사용자의 로그 자체도 개인정보이기 때문에 수집하는데 한계가 있습니다. 분석에 필요한 데이타가 결정이 되면 실사용자 중 테스터를 모집하고 동의를 얻어 사용 로그를 수집할 수 있게 변형된 앱을 설치하는 방법을 사용하기도 합니다.

트위터의 공개된 API로 사용 로그와 유사한 데이타를 얻을 수 있습니다. 사용자에 대한 정보, 사용자가 남긴 트윗에 대한 상세한 정보를 구조화된 형태로 받아올 수 있습니다. 사용자별로 최근 200개의 트윗을 받아서 분석에 사용했습니다.


사용 행태 시각화를 통해 사용자 유형 발견


유형화(clustering)한다는 것은 비슷한 특성끼리 모으고 또 다른 것을 나누는 작업입니다. 언어적이거나 수치적인 정보를 유형화하는데는 비용이 크지만 이것을 시각화하면 수월하게 처리할 수 있습니다. 시지각은 유사한 특성과 패턴을 병렬처리를 통해 빠르게 찾아내는데 최적화되어 진화되었습니다.
기존의 퍼소나 방법에서도 사용자 유형을 나누는데 시각화 방법을 활용합니다. 사용자 조사 결과에서 유의미한 행동 변수(특성)들을 추출하고 유사한 경향을 보이는 사용자를 그룹화하는데, 이를 위해 행동변수를 축으로하여 사용자들이 어느 정도에 위치하는지 표시하여 가까운 거리에 반복적으로 등장하는 유사한 성향의 사용자를 찾습니다.
하지만 사용자 수와 행동 변수가 많아지면 다양성이 더 크게 나타나 유형을 나누기가 모호해집니다. 유의미하다고 생각되는 행동 변수를 취사선택하여 단순화하는 작업을 필요로 합니다.

출처: About Face, Designing for the digital age

사용 행태를 볼 때는 사용자별로 시각화하여 사용 패턴이 드러나도록합니다.
사용 변수의 패턴이 드러나려면 많은 정보를 동시에 표시하면서 복잡해지지 않도록 해야합니다. 사용 행태의 특징이 드러나는 정보를 찾으면 그것을 위치,색상, 크기, 형태 등 시각적 특징(visual features) 중 하나와 맵핑하여 나타냅니다. 다차원적인 정보를 다차원의 시각 특징에 담아 섞이지 않게 하여 인지 비용을 줄여줍니다. 변수가 연속적이면 위치와 크기 같은 연속적 시각 특징을 활용하고 비연속적이면 색상,형태 등 비연속적 특징을 사용합니다. (색에서 명도와 채도는 연속적인 차이를 보이는데 사용합니다)

트위터에서는 우선 사용자들이 언제 얼마나 빈번히 트윗을 남기는지, 그것이 자신이 직접 쓴 것인지, 리트윗 한 것인지가 궁금했기 때문에 시간을 하루 24시간과 날짜, 2차원으로 나눈 위치 공간에 배치하고 트윗 유형을 색상을 이용해 구분 표시하는 걸 기본 구조로 잡았습니다. 위치는 중요한 시각적 자원이라 보통 시간은 1차원만 사용하고(x축) 그다음 가장 중요한 정보값을 다른 1차원(y축)에 나눠 배정하는게 일반적입니다. 대부분 그래프가 그렇죠. 여기서는 하루 주기의 패턴이 중요하다고 생각되어 2차원을 모두 사용했습니다.



트윗 사용 패턴 시각화

시각화는 애자일 방법으로 진행합니다. 실제 데이타를 적용한 시각화 결과를 보고 그다음 우선순위의 변수들을 찾아 추가하는 과정을 반복합니다. 유형을 나누는데 유의미한 정보가 무엇인지 찾기 전까지 알 수 없기 때문에 시도를 반복하는 게 최선의 방법입니다.
사진이나 동영상을 첨부하는 것이 리트윗 등 관심을 얻는데 주요한 요소인지 확인해보기 위해 기본 트윗 도트위에 사각 형태로 부속 속성을 주었습니다. 모바일인지 PC에서 사용하는지의 구분은 테두리로 표시하고 태그나 링크를 사용했는지는 텍스트로 표현했습니다. 이런 식으로 먼저 표시한 정보와 시각적 특징이 겹쳐지지 않도록 정보의 레이어를 쌓아 올리는 과정을 반복합니다.

시각화가 잘 되면 정보 요소들이 만들어내는 패턴을 통해 사용자의 유형이 스스로 드러나게 됩니다.


트위터 사용자 유형


트위터는 상호 친구 맺기가 아닌 구독하기(following) 모델을 사용합니다. 그래서 싸이월드나 페이스북처럼 오프라인 지인 기반으로 네트웍이 만들어지기보다는 관심사를 기반으로 새로운 네트웍이 형성됩니다. 별거 아닌 개인적인 일상의 소소한 자랑거리에도 내 친구들이 보여주는 따뜻한 반응에 익숙했던 사람들은 follower들의 냉혹한 무관심에 놀라고, 뉴스와 정보를 빠르게 얻을 수 있다는 말을 듣고 가입한 newbie들은 휑한 타임라인에 당황합니다. 카페나 커뮤니티는 관심 주제를 위한 하나의 공간에 사람과 정보가 모이기 때문에 수동적으로 정보를 소비하는 형태로도 참여할 수 있지만 트위터에서는 스스로가 능동적으로 관심을 위한 네트웍을 형성해야 합니다.

그래서 트위터를 분석할때 관심 내용인 키워드나 네트웍에 중점을 두고 분석하고 시각화하는 경우가 많았습니다. 하지만 그럴수록 개개인의 사용자는 잘 드러나지 않습니다. 수많은 데이타의 한 점이 되어 버립니다.

사용자가 남긴 트윗의 정보 요소를 추출해 사용자별로 시각화하면 사용자 유형이 확연하게 드러납니다.
아래는 두드러지는 유형을 몇 가지 모아봤습니다.


일반적인 사용 패턴

자기 트윗(파랑)도 하고 RT(초록)도 하고 다른 사람에게 멘션(보라)이 적당히 섞여 있는 형태가 됩니다.



애니프사

관심 분야 리트윗이 많습니다. 사진이 첨부된 트윗이 대부분입니다.(초록+노랑).
관심 주제에 깊게 몰입합니다. 오프라인에서의 실제 정체성을 드러내지 않고 프로필 사진으로 애니메이션 사진을 주로 사용해서 애니프사라고 합니다.

트윗 스트림을 샘플링 해보면 국내 트위터 사용자 중에 애니프사와 아이돌팬과 같은 팬덤이 가장 큰 비중을 차지합니다. 수동적으로 정보를 소비하는 사용자에 비해 압도적으로 트윗수가 많기 때문에 더 비중이 높아 보이는 면이 있기도 하지만요.
앞에서 얘기한 대로 트위터에서는 관심을 통해 네트웍이 형성되어 있기 때문에 트위터 사용자는 사실 모두가 덕질을 한다고 볼 수 있습니다. 그것이 자기 일과 관계있으면 실제 자기 정체성을 드러내고 그렇지 않으면 불필요하게 드러내지 않을 뿐입니다. 관심 주제에 열정적이지 않으면 트위터에서 흥미를 잃고 도태되어 살아남기 힘들거든요.


아이돌 팬덤

애니프사와 비슷하나 관심 주제가 아이돌입니다.
짧은 시간에 많은 트윗이 겹쳐있어 화면에는 적어 보이지만 하루 트윗수(104)가 많습니다
선별하여 리트윗하는 사용자와는 패턴이 확연히 달라서 리트윗을 페이스북의 "공유하기"보다는 "좋아요"에 가깝게 사용하는 것 같습니다.
동영상(빨강) 위주로만 리트윗하는 경우도 있습니다.



팬덤 컨텐트 생산자

직접 올리는 컨텐트 주로 아이돌 사진(파랑 + 노랑)이 많습니다.
멘션(보라) 비율도 높습니다. 정보를 공유하는 데 집중하는 사용자와 공통의 관심을 가진 사람들과의 소통을 중시하는 사용자 유형이 나뉩니다.



촉매자형 인플루언서

자기 트윗 비율이 높습니다. 링크로 관련 업계 소식을 전하는 비율이 높지만 단순히 큐레이션하여 소개하기 보다는 의견을 덧붙이는 것이 주가 됩니다. 정보를 단방향으로 전달만 하는 것이 아니라 관련 의견을 멘션으로 받고 선별하여 리트윗합니다. 팔로워들의 다양한 경험과 전문 지식을 매개하는 역할을 합니다. 




작가

직접 컨텐트를 생산하는 크리에이터는 작업을 소개하는 채널로 사용합니다.



미디어 봇

정해진 시간에 정해진 양식(기사 요약+사진)으로 기계적으로 트윗합니다.
대부분의 미디어 계정은 예약 기능을 이용해 주기적으로 자사의 기사나 뉴스를 노출합니다.



불법 사이트 홍보용 봇

기존 사용자 계정을 해킹해서 팔로워들에게 광고를 뿌립니다. 언팔 당하지 않으려고 광고를 너무 자주 뿌리지 않는 꼼꼼함을 보입니다. 타임라인 노출 효율을 높이기 위해 한두 시간 간격으로 20개 정도씩 집중적으로 트윗합니다.

같은 로봇 계정을 서로 팔로우하고 서로 리트윗해줍니다.
스팸 필터에 걸리지 않기 위해 단어를 랜덤하게 짜깁기해 내용을 매번 다르게 작성합니다. 하지만 아직은 알파초 수준이라 이런 패턴은 더 쉽게 발견해 차단할 수 있을 것 같지만, 트위터에서는 별로 신경 안 쓰는 것 같습니다.



홍보용 계정

자사 상품 홍보(파랑+사진)와 고객 응대(보라)로 구성되어 있습니다.
업무니까 업무시간에만, PC에서 트윗합니다.



고객과 관심을 공유하는 홍보 계정

자사 출판 서적 홍보(파랑)만이 아니라 IT 관련 업계 소식을 리트윗 하며 고객과 공통의 관심을 가지는 계정이라는 정체성을 유지합니다.



인스타그램(노란색)에 연동만 한 계정

오프라인에서 많은 팬을 가지고 있는 celeb들은 하나의 추가적인 채널로서 트위터를 사용하기도 합니다.



정치인 계정

페이스북(진한 파랑) 연동이 대부분입니다.
대부분 본인이 아니라 사무실에서 계정 관리를 하다 보니 PC(테두리표시)에서 올리는 경우가 많습니다.
소통보다는 알림 채널의 하나로 사용합니다.



본인이 직접 관리하는 정치인 계정

본인이 직접 양방향 소통의 채널로 사용합니다.
공교롭게도 이번 총선에서 이 분은 당선되고 앞의 분은 낙선되었네요.



백악관

해쉬태그(#)와 관련 인물 간접 멘션(@) URL 링크를 활용하여 보다 자세한 정보를 제공합니다. 정부 업무나 행사, 정책에 관련된 것이면 다른 계정의 리트윗도 많이 합니다. 

첨부된 사진의 경우 이슈에 대한 인포그래픽과 행사의 내용을 알 수 있는 참가자 위주의 사진을 주로 사용합니다. 



청와대

사용 패턴만을 보면 대통령의 미니홈피 사진첩이 더 적합해 보입니다. 

점심시간은 꼭 지킵니다.



고양이 계정

주인은 PC에서만, 고양이는 모바일로만 트윗합니다. 계정 바꾸기가 번거롭기 때문이겠지요.
사람 자체에 대한 관심보다는 그 사람이 생산하는 컨텐트에 관심을 가지고 팔로우하고 내가 관심없는 노이즈가 많아지면 언팔하는 구조다 보니 계정의 캐릭터를 집중해서 키워가는 양상을 보입니다. 그래서 멀티 계정을 운영하는 사용자들이 많습니다.



사용이 현저히 줄어드는 계정

남들의 반응(리트윗,라이크,멘션)이 없으면 트위터에 흥미를 잃어갑니다.
서비스의 주 사용자 층 외에도 이탈하거나 사용이 줄어드는 사용자들만 뽑아서 패턴을 찾아보면 서비스 개선 인사이트를 얻는 데 도움이 될 수 있습니다.



사용자 유형으로부터 퍼소나 만들기


로그 데이타를 이용한 사용 행태의 유형화가 바로 퍼소나로 이어지지는 않습니다. 로그 데이타는 퍼소나를 만드는 ABC Attitude, Behaviors, Context 중 행위 위주의 정보만을 담고 있습니다. 기존의 정성적 조사를 병행하여 사용 맥락을 확인하고 또 로그에는 포함되지 않는 오프라인에서의 행태를 알아보고 보완할 필요가 있습니다.

데이타를 이용한 사용 행태 유형화를 먼저 진행하여 인터뷰 대상을 보다 구체화하고 참가자 섭외하는 데 활용할 수도 있습니다. 또 심층 인터뷰에서 맥락을 확인하는데 기억을 되살리는 데 도움이 되기도 합니다.

서비스를 디자인하는 데 있어 사용자를 이해하는 것이 무엇보다 중요합니다. 기존 퍼소나는 처음 서비스를 기획할 때 주로 사용하고 이후 서비스를 운영하면서는 lean startup과 같은 사용자 데이타를 활용해 서비스를 개선하고 최적화하는 방법을 사용합니다.  

서비스 개선을 통한 성장 변화폭이 둔화하는 시점이라면 초기 목표로 삼았던 대상 고객과 현재 사용자의 구성이 달라졌을 수도 있습니다. 개선을 통한 부분 최적화를 계속 할 것이 아니라 로그 데이타 기반의 퍼소나로 다시금 사용자가 누구인지 이해하고 그로부터 서비스의 혁신 또는 피봇을 꾀하는 것이 필요할 수 있습니다.

현재 서비스를 운영하고 있었다면 우선 로그를 활용해 사용자 행태를 시각화하고 실제 사용자의 유형을 파악해 보는 작업을 해보는 게 어떨까요?



[참고##퍼소나##]




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


Trackback 0 Comment 0
Ad Test...