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

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

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

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 : 고은, 김민해, 김우리, 김지수, 김현철, 김희조, 노지훈, 박종국, 신수연, 오민애, 유지형, 윤미영, 이희덕, 정동준, 정영록, 최원석, 황지순

두번째 모임을 가지게 되었습니다. 두번째 모임은 과연 Stackeholeder란 무엇인가 입니다.

앞에서 했던것처럼

what? -> why? -> how 이런식의 순으로 분석해 보려고 합니다.

일단은 .. stackholeder란 무엇인가 what은 우리가 온라인 회의때 찾아본것의 정의는


What

회사의 사업자 요구를 파악하여 이해관계자 혹은 의사 결정권자들의 지지를 얻어야만하기 때문에 프로젝트를 실행

하기 위한 가장 첫번째 단계라고 합니다. 


이것은 온라인 회의 내용을 간략하게 정의 한내용입니다..

다음 내용은 How와 Whay의 대한 스터디한 내용의정리입니다.


Why의 내용은 각 색상별로 그룹화 시켜 본것입니다. 각각의 4가지의 그룹의 주제츨 잡아봤습니다.


Stakeholder를 하는 이유는?

1. 일정/인적자원을 산출
2. 리스크 방지
3. Stakeholder 요구사항 정리
4. 방향성 제시