12월 19일 MSP 1기~ 3기까지 모이는 홈커밍 데이를 하였다.~~

각각의 나와 다른 사람들이 새로운경험과 새로운 이야기를 들을수 있어서 매우 즐거웠던거 같았다.

이번 블로깅은 한번쯤 어더한 기술을 소개하는 포스팅이 아니라 한번쯤 개발자라면 한번쯤 생각 해볼만한 주제를 가

지고 블로깅을 하려고 합니다. 

자 이야기를 시작해보자. 소프트웨어 개발 방법론이란 용어는 전산과를 나온학생들이라면 한번쯤 들어봤을만한 말

이다. 그럼 소프트웨어 개발 방법론이란 무엇일까? 그냥 한마디로 표현하자면 소프트웨어를 개발 하기 위해서 필요

한 방법이라고도 말할 수 있다.  공대생이나 작은 단위로 프로젝트를 한 개발자들은 왜 소프트웨어 개발 방법론이 필

요한가라는 의문을 가질수 있을 것이다. 그러한 여러가지 방법론을 거치지 않아도 충분히 그러한 개발을 할 수 있을

텐데 라고 말이다.  그러한 생각은 작은 규모의 회사이거나 혹은 마음 맞는 몇명에서 개발을 했던 경험이 있기 때문

이다. 물론 그러한 회사들이 개발 기간과 시간등을 여러 소프트웨어 개발 방법법론보다 더 효율적일 수 도 있다.
 
보통은 체계적인 개발된 문서가 없더하더라도 개발자 본인의 머리에 들어있는 경험과 코딩을 바탕으로 문제점을 해

결 할 수 있기 때문이다. 그러나 만약에 회사의 규모가 성장함에 따라서 그러한 주먹구구 개발 방법을 유지하고 있다

면 개발 과정은 점점 혼란스러워 질것이다. 게다가 대부분의 정보를 가지고 있는 개발자가 퇴사까지 한다면 말 그대

로 절망적일 것이다. 즉 개발 방법론은 특정 개발자에 의해 편중되어잇는 점을 개발방법론 시스템에 따라 손실을 최

대한 줄여야 하는 것이다. 처음에는 문서도 제작해야하며 방법론의 프로세스에 따라가야하기 때문에 주먹구구식의

방식보다는 시간과 돈이 좀더들어가겠지만 그 대가로 손실을 좀더 줄일수 있다는 점이 되겠다.

그렇다면 소프트웨어 개발 방법론은 어떻게 배워야 할까?

 보통은 소프트웨어 개발 방법론은 책이나 인터넷을 통해 배우고 그것을 통해 그럴싸하게 개발과정을 따라 한다. 그

러한 개발과정으로 회사나 개발자는 흉내 낼수 있을 것이라고 생각을 한다.  

  그렇나  실제로 따라해보면 생각만큼 잘 되지 않지 않는다. 그래서 여러 회사들은 컨설팅회사에 문의를 하고 하지

만 그것또한 컨설팅 회사가 이론적인 것은 잘알지면 경험이 부족하다면 그 의뢰를 요청한 회사의 기업과 프로젝트의
성격을 무시한채 올바른 방법론을 제시해줄수 없을것이다. 또 회사는 컨설팅회사가 정해준 방법론대로 모든 개발을

그 프로세스에 따라 개발하는것도 쉽게 빠질수 있는 것도 문제이다. 간단한 프로젝트에 모든 이런 과정을 도입한다

면  과도한 비용을 지불할 수 도 있기 때문이다. 이것은 애초에  개발 방법론을 도입한 이유를 망각하고 무조건적인

강요로 인한  효율성을 떨어 뜨리기 때문에  유연하게 적용시킬수 있는 여지를 남겨두어야하기 때문이다.

위와 같이 설명했다 싶이 방법론의 궁극적인 목적은 효과적인 개발에 있다. 즉 빠른 시간안에  적은 비용을 들여 요

구하는 품질의 소프트웨어를 만들어 내는 것이다. 즉 돈을 잘 버는것에 있다.

 즉 소프트웨어 개발 방법론은 어떻게 이렇게 해야한다는 적당한 방법은 없다. 각 회사의 특성과 프로젝트의 구조에

따라서 유연적이게 변화될수 있어야 좋은 방법론이라고 할 수 있다.

요번주는 uxpedia모임과 별개로 김창준님이 세미나를 해주셨다..

세미나 내용은 "ux와 개발이 협업하는 방법"에 대하여 설명을 해주셨고 전체적인 내용은 이론적인 설명보다는

토의와 실습을 통해 진행되었습니다..

일단은 그룹별로 팀을 나눴습니다. 팀은 각각의 비슷한 성격으로 분류를 했더군요 그 이유는 일을 할때에는 비슷한

특징의 성격이 있는 사람들끼리 일을 하는것이 더 능율적이라고 하기 때문입니다. 그렇기때문에 이번 실습에는 하나의 성격을 가지고 했습니다 그 한가지규칙을 잘지키느냐 못지

키느냐라는 기준을 가지고 시작했습니다. (KAI라고 하는데 .. 까먹었음 ㅡㅡ;;)

규칙을 잘지키느냐 못지키느냐는..한순간의 규칙이 아니라 장기간에 걸쳐 꾸준히 할수 있는 규칙을 말합니다.

규칙을 잘지키는 사람은 예를 들어 마인드맵을 그릴때 논리적이고 체계적으로 생각을 하지만 규칙을 안지키는
 
성격을 가진 사람은 두서 없이 생각나는데로 쭉 적는다고 합니다. 그렇기때문에 일을 할때에도 그러한 성격의 사람

들끼리 모아서 하면 더 능률적이라고 합니다.  그런것을 기준으로 3명 or 4명으로 팀을 김창준님께서 제시한 두가지

상황의 문제중 한가지를 선택하여 풀기로 했습니다.

상황1.

당신은 인터넷 서비스회아세 ux담당자입니다.  기능직이며  부서에 대리정도 됩니다. 다른 팀원들은 각자 프로젝트를 합니다. 부서장은 당신을 신뢰하고 있습니다. 인터넷 서비스의 next는 무엇인가? 라는 주제로 인터넷 기업에서 위기감을 느끼고 있습니다. 그래서 전략 그룹에서 분석을 했더니 인터넷 서비스의  next는 information overload가 굉장이 중요하면 그것을 해결 해야된다고 했습니다. 그래서 개발 팀장 한명을 찍어서 테스트를 해 인터넷 서비스의next를 보여줄수 있는 서비스를 해라라는 말을 들었습니다. 그 개발 팀장 한명은 개발 능력을 인정 받고 있습니다. 그 사람이 개발자를 수소문해서 개발자 4명을 모았고 디자이너 한명 기획자 한명 프로젝트 매니저 한명 ux한명 또한 포함되었습니다. 사장은 3개월 후에 프로토타입을 보고 싶다(중간점검) 그것을 패스하면 3개월을 더준다 그리고 최대한 그 프로젝트를 할수 있게 지원을 해준다고 했다. 나는 ux담당자이며 처음 미팅을 하는 자리이다.


상황2.
폐쇄회로 카메라 중소기업이면 개발자는 50`60명이고 디자이너는 없다. 연구소 소속이며 ux를 한 나에게 디자이너 역활도 기대를 한다. 기업의 목표는 고객이 열광적인 것을 만들어보자라는 목표를 가지고 있고 팀의 개발자는 5명 이며 모두 ux는 모른다. 지금이 8월(시작 날짜가 기억안남 -_-;;; )로 가정했을때 내년 2월까지 상품화를 목표를 잡고 있으며 이미 있는 것에서 개선하는 상품이며 그러한 개발을 할때 개발자들은 모두 각장의 개발스타일때문에 싸우고 있다. 이때나는 신입사원이며 힘이 없다.




이러한 두가지 문제점이 있고 각자 ux를 담당하고 있는데 어떻게 적용을 할수 있을까에 대한 여러가지 토의를 했다.

각자의 팀에서 ux를 적용시키려는 사안중에서 1번 문제와 2번문제에서 실무에 접했을때 이러한 문제점이 일어날수 있다는것을 알 수 있었다.

상황 1의 문제점
1. 사장,개발자 팀장과의 마찰
2. 사장이 그 프로젝트에 중요하지 않게 생각할 수도 있다.
3. 사장은 개발에 대한 전반적인 지식이 없을 수 있으면 (사장은 티를 안내려고 한다)
4. 개발자는 자신의 프로젝트의 확신을 가지고 있다. (절대 실패하지 않을거라는 확신)
5. 시간이 촉박하다.

상황 2의 문제점
1. 신입 사원이므로 개발에 대한 전반적인 지식이 없다고 생각함.
2. 신입 사원 이므로 전반적인 발언권이 적다.
3. ux를 적용시키려고 하지만 시간에 대한 개발자의 의견 충돌
4. 각기 다른 개발자의 상충되는 의견
5. 시간 문제

최근 인터넷 서핑을 하다가. 어떤 한가지 동영상을 보게 되었다. 그 동영상은 아래와 같은 동영상이다.


동영상을 보니 각각의 ms의 제품군들 오피스 아웃룩등이 집안에 있는데 사용자가 나가지만 제품군?들은 집안을 빠

져나가지 못한다. 그렇지만  유저가 핸드폰을 꺼내자마자 제품군들이 집밖을 빠져나와 사용자와 함께 같이 움직일수
있게 된다.  이런 동영상을 보면 집안 에서만 하던 작업을 이제 집밖에서도 휴대폰을 사용해서 지원을 한다는 의미의
동영상이었다. 이 동영상만 본다면 ms에서 폰을 만드는거였나 하는 착각에도 빠질수 있지만. 찾아본결과 이번 ms

에서 발배될 모바일즈 윈도우 6.5라는 것임을 알게되었다.  그래서 이번에는 모바일 윈도우 6.5에는 관심이 있어서

블로깅 주제로 선택하였다.

 기존 모바일 윈도우즈은  한국 시장에서는 좋은 평가를 받지 못했던거 같다 그 이유는 애플이나 다른 경쟁사의 UI 비

해 딱딱한 윈도우 기반 UI를 벗어나지 못한 이유이다. 그래서 이번 윈도우 모바일 6.5에서는 새롭게 UI를 뜯어 고치고
있다. 또한 모바일 윈도우는 비즈니스 이용자에게 장점을 제공해주는 특징이있다.

특징

1. 기존과 다르게 인터페이스 개선.
2. 비즈니스 사용자에게 편의성 제공.
3. 인터넷브라우저를 개선
4. 넓은 하드웨어 선택폭
5. 모바일 마켓 플레이스 제공

자 특징을 살펴 보자 첫번째는 기존의 윈도우 모바일의 UI를 버리고 새롭게 인터페이스를 개선한 점이다. 아래의 사진을 보면 알수있다.

딱 봐도 뭐가 좀더 쉽고 복잡하지 않게 일반사용자들이 접근할수 있어 보인다.  왼쪽사진은 좁은 휴대폰 액정화면에 여러가지를 구겨 넣은것처럼 보이고 오른쪽은 각각 필요한것이 잘 정리되어있는 인터페이스처럼 보인다. 척봐도 왼족사진에 있는건 건드리기가 싫어진다..

 두번째는 비지니스 사용자에게 편의성을 제공해줄수 있다. 즉 위의 동영상과 같이 비즈니스 사용자에게 편의 성을 제공하여 언제 어디서나 휴일이든 평일이든 일을 할수 있는 퍼펙트한 근무환경을 제공한다는것이다.. ( 장점인지 단점인지는 잘 모르겠다..)

세번째는 인터넷 브라우저를 개선했다는 점이다.

또 기존의 인터넷 환경은 어도비의 플래쉬를 많이 사용한 페이지가 많은데 이 모바일 브라우저에서는 어도비 플래쉬
라이트도 지원한다. 그리고 위의 스크린샷과 같이 줌인스크롤이 있어  이전보다 깔금한 브라우저를 제공해준다.
 
 네번째는 넓은 하드웨어 선택폭을 들수가있다. 기존의 애플와 달리 모바일 윈도우는 하드웨어 선택폭이 넓다고 말
할수 있다 즉 카메라나 물리적키패드를 선택할수 있다는 말이된다. 즉  이말은 각각의 휴대폰 제조자 삼성이나 엘지
같은 기업들이 모바일 윈도우 6.5기반 휴대폰에 올린다면 고정적으로 터치면 터치만 써야되고 카메라면 카메라만 쓰
는것이 아니라. 윈도우 모바일 6.5 만의 막강한 라이브러리를 가지고 각각의 휴대폰의 특징에 따라 변경해줄수 있다는 말이다. (os를 올리는 것과 올리지 않은 것의 간단한 차이점은 예전에 기술블로깅을 참조하시면 된다)

다섯번째는 모바일 마켓플레이스를 제공해준다. 모바일 마켓플라이스는 개발자가 개발을 하거나 이용자가 제품을 구입하기 까지의 과정은 본래 복잡하지만 그러한 장벽을 낮춰 누구나 개발을 참여할수 있고 누구나 이용자가 그 제품을 구입할 수 있는 환경을 제공해줄 수있는 점이라고 볼수있다. 아마 아이팟이 성공하게 된이유는 편한 UI도 되겟지만 엄청난 수의 어플리케이션이라고 생각 한다.

이렇게 윈도우 모바일 6.5의 특징들을 몇가지 뽑아보았다. 윈도우 모바일이 적용된 스마트폰의 경우 분명 기본의 일반적인 폰에 비해 기능면에서는 우수하다. 그러나 스마트폰에 대한 많은 사람들의 인지도가 부족하다. 기존의 폰과 많은 기능때문에 조금은 더 복잡하기 때문이다. 그리고 무선인터넷이 지원되 많은 사람들이 무료로 인터넷을 사용할수 있겠지만 wifi에 대한 홍보나 사람들의 인식이 많이 부족하다. (보통 사람들은 휴대폰이나 모바일 기기로 인터넷을 한다면 비싼 이용료를 지불해야된다고 알고 있다.). 그렇기 때문에 사람들의 인식을 변화시켜준다면 윈도우폰또한 아이폰 못지 않은 열풍이 될수 있을것 같다.


부족한 점이나 틀린점이 있다면 과감히 댓글로 알려주세요 ^^;

그리고 내용이 마음에 드신다면..아래 클릭 해주세요 ^^;

이번주에는 컨셉 디자인과 컨셉 맵에 대한 스터디를 하게되었습니다.

그중에 우리팀은 컨셉 디자인에대한 토론을 해보았습니다.

온라인회의에서 컨셉 디자인이 무엇인가?에 대해 알아보았는데.. 일단 정의는 아래와 같습니다.

What

1. 컨셉디자인란 ?제품을 완성함에 있어 아이디어나 디자인을 시각적으로 보여주는것을 말한다.

2. 아이디어를 구체화 +  비주얼라이징

여러가지 아이디어를 그림으로 먼저 테스트를 하여 어떤 디자인 방향이 맞는지 판단하고 그 아이디어를 구체화 시키는 과정을 총해 추상적인 아이디어를 구체적인 시각요소로 바꾸는 작업의 첫단계.

자세한 내용은 uxpedia 까페

Why?


인터넷이나 여러 사이트를 돌아다니다보면 컨셉 다지인으로 된 아이폰이나 여러가지 디자인을을 볼수 있을것이다. 

그런 컨셉디자인은 기획안이 가안들이 정해저있을때 여러 사람들에게 그러한 제품의 이미지를 구체화 시켜 내부

Image 공유 커뮤니케이션을 향상 시킬수 있고 그것에 따른 의견 통일이 가능하다. 또 컨셉 디자인에 대한 점검 을 할

수 있고 user에게 그 컨셉을 제시하고 피드백을 받을수 있는 점이 때문에 컨셉 디자인한다는 의견을 내보았다..

How

다음에는 how에 대해서 알아보았다. 일단은 컨셉 디자인의 사용방법은 3가지가 있을것이라고 생각을 해보았다. 첫

번째는 제일 처음에 제안하는것, 두번째는 프로젝트 중간중간에 계속해서 바뀌는 컨셉  마지막으로 마지막에 제시되

는 컨셉디자인이 제시되는것이다. 처음에 제안할때는 아이디어에 대한 구체화를 하기위해 처음 제시된다 모든 과정

이 진행되기전 가장처음에 사용되면 예를들어 게임의 마을이나 케릭의 원화를 통할때 사용될수 있겠다. 다음으로는

기획이 진행되는 모든 프로세스 중에 제시가 된다 이경우에는 웹사이트와 같이 한번 컨셉과 디자인이 그 틀안에서

계속되서 리뉴얼시키면서 사용되는 방법. 마지막에는 하드웨어의 경우 한번 출시될경우 변경이 어렵기때문에 가장

마지막 단계에서 디자인의 검증을 받기위해 사용될것이라고 의견을 내보았습니다.


UX에 관련있는 방법론일까?

간략하게 정리를 하고 토론을 하는 결과 컨셉 디자인이 왜 ux에 관련된 하나의 방법론중 하나일까 많은 고민을 했습

니다. 찾는 자료중에도 모두 디자인 측면에서의 자료가 많아 애를 먹었습니다. 하지만 토의를 해본 결과 UX 에서 보

는 컨셉 디자인은 논리적인 제품의 인터페이스 and 구현과 시각적 기획 , 어떤기능이 붙어야하는지를 정의해야하

고 , UX리서치의 산출물이라는 이야기가 회의 마지막 부분에 나왔습니다.  정리를 하자면  컨셉 디자인은 그러한 불

편한점을 ux리서치 조사를 통해 각각의 사용자의 요구사항을 뽑아내고 그걸 토대로 논리적인 제품의 인터페이스를

구현하기 위해 컨셉디자인을 하는것이라고 토의를 해보았습니다.




잘못된거나 이상한점 있으면 가차없이 지적해주시면 감사하겠습니다..

uxpedia까페도 활동중이니 많이 방문해주세요

자 이번주에는 3주차...Ethnography대해서 열띤 토론을 했습니다..

일단 Ethnography가 무엇인지 살펴 봅시다.

 일단 Ethnography를 사전적인 의미가 무엇인지 정확하게 파악을 하지 못한 상태여서 사전적의미를 파악
한 후에 방법론적인 생각을 해보기로 하였습니다.  
Ethnography의 사전적인 의미는 아래와 같습니다.

민족지 [民族誌, ethnography]

현지조사에 바탕을 둔 여러 민족의 사회조직이나 생활양식 전반에 관한 내용을 체계적으로 기술한 자료.

즉따로 살펴본 정의 또한 "식민지 개척공식보서로부터시작", "문화인인류학"보고서형태" "지역, 문화의 특색"이라고 정의를 내렸습니다.

또 그 정의와 다르게 방법론적 의미를 정의해 보았습니다.

방법론적인 의미

우리가 아니라 타 그룹을 대상으로 다른 문화 다른 지역의 불편한 니즈를 포함하는것 무엇이
찾아내는 방법

이라고 정의를 내리게 되었습니다. Ethnography가 이것이다 라고 정의를 내렸고 이정의를 바탕으로 왜 이것을 해야되는지 정의를 내려보았습니다

과연 Ethnography를 왜 해야될까요?

타그룹이나 타문화 사람들이 당연하다고 생각하는 것을 제 3자의 입장에서  미처 발견하지 못했던 필요를 충족해줌으로서 새로운 만족감을 제공할수 있기 때문이다. 예를 들어 국산 온라인게임등이 한국이나 아시아권에서는 인기를 얻었지만 유럽권 나라에서는 인기를 끌지 못하는 이유도 이와같은 것에 포함된다. 각 다라의 고유의 문화와 특색과 취양이 있지만 그것을 고려하지 않았기 때문이다. 물론 이것은 단 한가지 예일 뿐이다.


결국 Ethnography를 사용하는 이유를 정리하면

Why

"각 다른 그룹이나 문화권 사람들이 무의석으로 행해지는 행동 3자의 입장에서 파악하여 미처 발견하지 못했던 필요충족을 하기 위해 사용한다. 즉 각각 다른 문화의 현지화하여 성공의 가능성을 높이기 위해 사용한다."




마지막으로 Ethnography를 HOW 어떻게 사용하는지 알아보았다. 방법으로는

간접적인 방법과 직접적인 방법 2가지로 나눌수 있다.

간접적인 방법은

TV, 사진등의 디지털 도구를 이용하여 그 문화는 이렇다 하고 간접적으로 느낄수 있는 방법을 말한다.

또한 직접적인 방법은
해당 문화를 직접 자신이가 체험을 하는 방법 이다. 그렇다 직접체험방법은 오래 걸리기 때문에 출발전 현지인이나 조사를 하고 싶다면 각 문화권에 거주하고 있는 사람들에게 일주일 정도 일기를 적게하여 오기전에 한번 읽어보고 직접체험을 하는 방법이 좋을 것이다.

단 조사대상이 자신이 조사받고 있다는 것을 의식하면 안된다. 의식하게 된다면 그 문화의 보기 좋은 모습만 보여주려고 하기 때문이다.


다음은 Ethnography를 통한 실습을 해보았다.

상황설정은 각각 다른 전공을 가진 학생들과 일상적인 이야기를 하고 있을때 어느 한사람이 그것을 기록하였다.
물론 무의식속에서 조사받고 있는 상태를 만든후 실습을 하였다.


작은 스터디 그룹에서도 각각 자신도 모르는 무의식속에서 어떠한 행동을 하고 어떤식의 대화를 하는지 알 수 있었다.


 uxpedia : http://cafe.naver.com/uxpedia.cafe

틀린점이나 고칠점 있으면 말씀해주세요...

지난 10월 10일 토요일에는 페르소나에 대해 오프라인에서 WHY와 HOW를 정리해보았습니다.

한번 그 날의 자료들을 정리해보며 페르소나에 대해 다시 한번 알아보겠습니다.

 

1. WHY

 

 

먼저 'WHY'에 대해 정리해보겠습니다.

 

이 작업을 수행하면서 상당히 흥미로웠던게 온라인회의에서 먼저 페르소나에 대해 'WHAT'을 정의하는 과정을 거치면서 당연히 'WHY'에서는 '사용자 니즈 파악'과 관련된 부분이 가장 많이 의견이 나올것 같았는데, 의외로 다 끝내놓고 보니 '커뮤니케이션'과 관련된 내용이 더 많이 나왔더군요.

이는 페르소나를 사용자 니즈 파악에 중점을 둘지, 전체 프로세스 진행과정에서의 일관성과 효율성을 통한 더 나은 아웃풋을 위한 커뮤니케이션의 질적 향상에 중점을 둘지 한번 생각해보게 하는 부분이었습니다.

 

우선 가장 많이 나온 커뮤니케이션 관련 의견을 보면 페르소나는 개발자, 디자이너, 스테이크홀더, 그리고 서비스를 최종적으로 사용하는(혹은 사용할) 유저 간에 동일한 개념에 대해 동일하게 이해하고 의사소통을 원할히 하고자 설정하며 이를 통해 의사토통에 있어의 장애요인을 제거하고  모두가 각자의 분야뿐 아니라 다른 분야 에서도 동일하게 이해하고 알아들을수 있게 합니다. 이를 통해 결정적으로 전체적인 UX 설계 및 집행의 흐름을 매끄럽고 일관성 있게 추진할수 있게 합니다.

 

그리고 많이 중요하게 파악된 니즈 파악 부분에서는 페르소나를 통해 대상을 명확하게 인식하고 이를 성별, 연령, 직업, 사회적 지위 등 다양한 분류로 나누고(sorting) 디테일하게 파악할수 있게 합니다. 이 모든 것은 다양한 사용자의 니즈와 의견을 최대하으로 파악하기 위한 것입니다.

 

전체적인 UX 설계 및 집행 프로세스 상에서 페르소나가 위치해 있는 부분을 보면, 유저 리서치 다음으로 이어지는 상대적으로 초기단계에 행해지는 방법론이라 볼수 있는데요. 유저 리서치를 통해 나은 결과값을 더욱더 실제적이고 쓸모있는 것으로 만들고 이를 통해 대사의 특징이나 요구사항을 구체적으로 분석해 사용자에 대한 관점을 이해하는 것이 목적이라 할 수 있겠습니다.

 

2. HOW

 

 

다음으로는 'HOW'에 대해 정리해보았습니다.

 

직접적인 페르소나 작성 이전에 고려할 사항으로는, 우선 프로세스상에서 페르소나는 유저 리서치를 통해 얻은 정성, 정량 조사자료를 기반으로 하여 만들어지는 것이기 때문에 신뢰성 있는 조사가 기반이 되어야 하며(유저 리서치의 타당성과 신뢰성을 높이는 방법은 후에 이어질 유저 리서치 부분에서 다룰것이기 때문에 깊이 들어가지 않았습니다.) 최대한 다양한 요구사항을 고려하여 한 제품/서비스에 대해 하나 이상의 페르소나가 존재한다는 사실을 충분히 인지하고 들어가야 합니다.

페르소나 작성과정에서 고려할 사항으로는 타당성과 신뢰성이 검증된 유저 리서치 자료를 페르소나로 재구성 하는 과정에서 조사자 임의에 맞게 자료를 재구성하는 일이 없도록 주의하여 마지막까지 오염되지 않은 페르소나를 뽑아내는 것이 중요합니다. 가장 기본이 되는 사항으로는, 고객 설문이나 사용후기의 양식을 통해 얻어진 자료를 통해  고객의 과거경험을 파악하고 이를 통해 니즈를 파악하고 가상의 고객(메타포)을 설정합니다(가상화). 이때 우리가 설정한 이 가상의 고객은 사실에 기반한 유저 리서치 자료를 통해 얻어진 것(실제화)이기에 신뢰할수 있는 데이터임을 늘 인지하고 있어야 합니다. 때로는 시장에 존재하지 않은 새로운 제품/서비스에 대해 페르소나를 설정해야 될 경우도 있습니다. 이러한 경우에는 사용한 적이 없기 때문에 사용후기라는 것이 존재하지 않고 고객 설문 역시 존재하지 않을수 있습니다. 이런 경우에는 최대한 고객의 잠재 욕구를 파악하여 존재하지 않는 가상의 사용자를 만들어야 하는 경우이기 때문에 이러한 경우에는 실체가 없는 것에게 실체를 부여하는 경우라고 할 수 있습니다

Ux Story 2주차에 대해서 정리해볼까 합니다..

이번 정리는 일주일전에 했어야했지만 엄청나게 바뻣던 저번주에 못했어요..

우선 저는 두가지 주제중 user story에 대해 공부를 해보았습니다.

user story란 
간단하게 말해서 마케팅이나 비즈니스 또는 개발자, 고객 등 여러 사람들간의 원할한 커뮤니케이션을 하기 위한 기법입니다.


user story의 장점
user story는 의사 소통 즉 커뮤니케이션에  목적이 있기 때문에 개발자, 기획자, 프로젝트 관리자, 개발자 모두가 명확히 무엇을 하는지 잘못된 방향으로 가지 않은지 빨리 구별을 할 수 있어야한다.


user story를  기록하는 방법

- 카드 :  스토리를 서술 형태로 기록, 계획하거나 기억하기 위한 단서로 사용
- 대화 :  스토리는 대화를 통해 세부사항을 구체화
- 확인 :  테스트를  통해 세부 사항을 문서화 하고 전달하며 스토리 완료여부 판단

카드를 통해 스토리를 서술 형태로 기록해야 한다 단 서술을 자체를  중요하게 보면안된다. 개발자와 고객간의 대화의 수단으로 사용하기 때문이다. 또한 user story는  고객의 입장에서 서술되어야 한다. 왜냐하면 기술적인 용어가 아닌 비즈니스 언어로 설명되어야 하기 때문이다  예를 들면  "나는 고객이니깐 당연히 무엇무엇을 해야한다" , "고객이니깐 당연히 이 기능은 있어야한다" 이런식으로 자신이 고객이라는 마음을 가지고 기술하는 것이 좋다.


이제 userstory가 무엇이지 간략하게 파악해보았다.. 그럼 왜 userstory를 왜 사용하는지 알아보자

이러한 결과가 나왔다.  .
 
즉 userstory는 다양한 전문야사람들이나 고객들을 대상으로 기존의 프로젝트나 마케팅에 맞게 커뮤니케이션을 원

할하게 해야한다. 다양한 사람들과 커뮤니케이션을 해야하는만큼 유저스토리는 사용자들이 원하는 명확한 기능을

추출하기 위해, 목표를 명확하기 위해, 그룹핑을 통한 기능의 흐름을 표현을 하여 설득력과 이해를 상승시키기 위해

사용된다.

userstory는 페르소나와 함께사용한다면 큰 효과를 누릴수 있다. 그 다음은 각각의 카드에 기능(목표) 문장을 적고

뒷편에는 그 기능(목표)의 테스트적어 그룹핑을 한다. 그룹핑을 한것을 각각의 주제로 정리를 한다면 기능(목표)의

흐름을 자연스럽게 알아볼수 있게 할 수 있다. 카드에 문장을 적을때에는 고객이나 사용자의 입장에서 당연히 "나는

고객으로서 ~이 필요하다 or 필요없다")라는 듯한 마음가짐을 가지고 작성을 하면된다.

노지훈 MSP께서 지난 번 수업을한 stakeholder Interview에 대한 내용을 아래와 같이 이해하게 쉽게 풀어서 설명해주셨습니다.


녕하세요! UX Pedia 가 첫 수업을 진행하였습니다. 이름도 다소 생소했던 Stakeholder Interview 라는 방법론에 대해서 철저히 파헤쳐 보았습니다. 스테이크가 나와서 뭐 레스토랑가서 인터뷰하는 거냐? 하고 생각하셨던 분들은 큰 코 다칠 겁니다. 잔뜩 집중하고 읽어 주세요 :^)

수업 방식은 온라인 리서치와 토론하는 과정을 통해 의견을 나누고 생각을 구체화하면서 방법론에 대해 인식해나가는 식으로 전개를 했습니다.

1. What / 정의

소프트웨어나 시스템 엔지니어링에서, 요구사항을 분석하기 위해 쓰는 기법으로 회사 안에서 새로운 프로젝트를 진행할 때 사업성에 관련된 측면이 고려 되어야 하고 이를 위해 회사의 사업적 요구를 파악하여 이해 관계자 혹은 의사 결정권자의 지지를 얻어야만 하기 때문에 프로젝트를 실행하기 위한 가장 첫 번째 단계가 된다. (Stakeholder = 의사결정권자, 이해관계자)

여기서 이해관계자란 클라이언트 중 프로젝트의 특정한 부분에 관심이 있고 그 결과에 직접적인 영향을 받는 사람들을 말한다.

즉, 본격적인 개발에 들어가기 이전에 프로젝트와 관련된 의사결정권자들의 생각을 듣고, 요구사항을 전달받는 과정이며 이들을 설득시켜 참여를 유도하고 1차적인 합의점을 찾아서 관련 아이디어를 창출하기 위해 사업 전략적인 측면에서 이루어지는 프로젝트의 시작점으로써 모든 분야에 앞서 포괄적으로 선행 되어야 하는 절차라고 할 수 있다.

부가적인 논의 (Stakeholder 를 User 로 볼 것인가?)

접기

접기

2. Why / 왜 하는가

• 프로젝트 진행 적합성을 판단하고 비즈니스적 목표를 구체화하여 방향성을 제시하기 위함.

• 투자자 / 클라이언트도 잠재적인 유저 Potential User 가 될 수 있다. 초기 아이디어를 다양한 계층의 Stakeholder 로 부터 검증하고 문제점을 파악한다. 또한 요구사항을 정리할 수 있다.

• 갑과 을의 관계에선 필수적인 절차이기 때문이다. 투자금과 같은 민감한 예산편성 문제에 직접적인 해결책이 될 수 있다. 또한 일정 / 인적자원을 산출하는 배경이 되기도 한다.

• "사장님은 UX를 몰라", "사장님은 헛꿈 꾼다" : 추가적인 리스크가 발생하지 않도록 하기 위해, 프로젝트 초기 진행 방향을 결정할 때 내부 전문가 (동시에 이해 관계자 인) 의 도움을 받아 실패의 확률을 낮출 수 있다. → 경영자에게 제공할 수 있는 객관적인 수치를 확립할 수 있다.

3. How / 어떻게 하는가

외부에 존재하는 잠재적인 사용자들을 조사하는 것이 User Research 라면, 조직 내부의 다양한 소리를 듣는 과정을 Stakeholder Interview 라고 다시금 정의해 볼 수 있겠다.

진행과정은 크게 "인터뷰 설계 - 진행 - 분석"의 흐름을 따라간다.

1. 문제사항의 이해 (프로젝트의 방향 설정) : 문제가 무엇인지 명확하게 정의하고, Interviewee 팀 자체에서 고민을 통해 포커스를 맞춘다.
2. 질문 리스트나 주제를 준비한다. 예상되지 않은 질문까지도 준비해야 한다.
3. 다양한 부서, 다양한 레벨의 Stakeholder 를 섭외한다. (다양한 니즈를 반영하기 위함)
4. 각각의 Stakeholder가 UX에 얼마나 어떻게 영향을 미칠 수 있는지 결정 한다. (예시 1 참조)
5. 인터뷰 진행시, Stakeholder 에게 자신의 Client 를 정확히 소개하고 이해시킨다.
6. 진행자는 어떤 Stakeholder 이더라도 UX를 파괴하고자 하지 않을 것이라는 것을 이해해야 한다. (Stakeholder 는 우호적인 인물이다. 마음가짐의 문제.)
7. Stakeholder 에게 Structure, Not to Structure, Semi-Structure 를 보여주어라.
8. 인터뷰 후에도 반복적이고 지속적으로 피드백을 받는다.

인터뷰 후 산출된 이슈들에 대해 중요도 별로 정리해 볼 수 있다. 이슈의 중요도를 정리하기 위한 방법으로 색이 다른 포스트잇이나 펜을 사용할 수 있다.

인터뷰 결과가 실제 프로젝트 얼마나 반영이 되는 지에 대한 투명한 공개가 필요하다. 이는 이해집단간의 마찰에 대비하는 효과와 프로젝트에 더욱 호의적으로 Stakeholder 들을 끌어들일 수 있는 효과가 있다. 투명한 공개를 위한 방법으로 Stakeholder 들을 직접 인터뷰 분석작업에 참여시키거나, 이들을 위한 공유회를 열 수 있다.

4. Reference

 

(예시 1. Stakeholder 의 영향력과 관련된 지표)
더욱 많은 레퍼런스는 UX Pedia 카페에 있습니다.

참여 UX Pedian : 고은, 김민해, 김우리, 김지수, 김현철, 김희조, 노지훈, 박종국, 신수연, 오민애, 유지형, 윤미영, 이희덕, 정동준, 정영록, 최원석, 황지순