bobozzang ::

1. 사용자(User)는 누구인가?

1) 사용자들이 원하는 것?
- 정보나 주제를 찾기 위해서
- 무엇인가를 배우기 위해서
- 업무 처리를 수행하기 위해서
- 어떤 것을 컨트롤하거나 모니터링 하기 위해서
- 무엇인가를 만들어 내기 위해서
- 다른 사람들과 커뮤니케이션을 위해서
- 즐기기 위해서
- 한가지 목적(task)만을 지향하는 사용 케이스와 사용자(User)는 다름
- 사용자들의 본능적인 반응, 신념, 가치 등의 '부드러운 요인(softer factors)'을 고려할 필요가 있음
2) 사용자 조사시 분석할 것들
- 사용자들의 목표
- 목표를 추구하기 위해 사용하는 특정 행동들
- 사용자가 자신이 하고 있는 행동을 나타내기 위해 쓰는 언어와 단어들
- 개발할 UI와 비슷한 UI를 사용하는 사용자들의 숙련도
3) 사용자 조사 방법
- 직접 관찰(사용자 테스트, 관찰)
- 사례 연구 : 통계청을 통해서 추출한다.
- 설문조사
- 페르소나
4) 숙련도에 따른 분류

2. 사용자(User)의 행동 패턴
1) 안전한 탐색 : 확실한 네비게이션
멀티 레벨 언두(undo)
2) 즉각적인 만족 : 에쿠스 견적내기 서비스(http://www.hyundai.com/PurchaseInfo/Estimation/Estimation_WinPop.aspx?estimationType=NORMAL&codeValue=E21&codeName=��&hdnIMAGEdefault=equus_vi.gif)
http://www.cyon.co.kr/event/arena/index.html
3) 최소한의 충족 : http://www.tossi.com/ sk텔레콤 작품
4) 흐름의 변화 : http://kuler.adobe.com/ 로그인을 해도 흐름이 끊기지 않는다
5) 선택 미루기 : http://kr.yahoo.com/ 야후메뉴의 <더보기> 서비스
http://www.runpipe.com/user/join.php
6) 구조 늘리기 : 다음지도 서비스<크게 늘리기, 작게 보기...>, 쇼핑몰의 가격늘리고 줄이기
7) 습관화 : http://www.bing.com/ 이미지 검색보기
8) 공간기억 : 습관적으로 사용한 레이아웃에 사람들은 편리하게 생각한다.
9) 미래 예측 기억 : 내가 예측할 것을 기억하게 해준다 ->버 스포츠 기능
10) 능률적인 반복 : 구입할 도서의 관련책 제공, 이책과 함께 구매한 책
11) 키보드만 사용하기 : 스프링 노트도 제공하고 있음
12) 다른이들의 충고 : 사용자 리뷰

3. 페르소나(Persona)
1) 페르소나의 정의
- 페르소나는 해당 웹사이트의 사용자를 요약하여 표현한 것
- 일반적으로 실제 사람처럼 묘사됨
- 어떤 프로젝트든 하나 또는 그 이상의 페르소나가 존재
- 각각의 페르소나는 웹사이트의 다양한 사용자 유형을 대표
- 페르소나는 사용자 프로필, 사용자 역할 정의 고객프로필 등으로 불림
2) 페르소나의 의미
- 페르소나로 사용자 니즈를 효과적으로 쉽게 묘사할 수 있음
- 페르소나는 타겟 사용자에 대한 리서치 결과로 만들어져야 함
- 리서치가 얼마나 심층적이냐에 따라 얼마나 복잡한 페르소나를 만들것인지 결정됨
3) 페르소나의 예
4) 페르소나의 개요
- 무엇을 위한 것인가?
   웹사이트의 기능/컨텐츠들을 설계하는 UX설계 업무에 필요
- 누가 사용하는가?
   페르소나는 결정적으로 기획/디자인과 관련된 의사결정을 할 수 있도록 정보를 제공하고, 방향을 결정할 수 있도록 함
   엔지니어들도 작업의 맥락을 파악하는 데 유용하게 활용

5) 페르소나를 만드는 10가지 순서
- 사용자들을 찾음
- 가설의 설정
- 가설들의 조합
- 패턴 찾기
- 페르소나의 설정
- 상황의 정의
- 페르소나의 확인 및 동의
- 프로젝트팀에 배포
- 시나리오 제작
- 업데이트를 통해서 세분화
6) 페르소나 기본사항
- 이름 : 사람을 나타내는 요약글로 이름이 필요함
- 역할 명칭 : 근심자, 다양한 계좌 보유자, 학습자 등
- 동기 : 사라는 당좌 예금 계좌를 개설하고 싶다 등
- 니즈 : 사라는 당좌계좌예금을 개설하려고 하며, 다양한 종류의 계좌를 비교하고자 한다. 그녀는 특히 최소 예금 잔고와 추가비용에 관심을 가진다.
- 시나리오 : '근심자'가 쇼핑하던 중에 그의 신용카드 승인이 거절된다. 그 고객은 집으로 돌아와서 왜 카드의 승인이 거절되었는지 확인하기 위해 카드 뒷면에 적혀있는 url을 찾아 방문한다. 그 고객은 자신의 계좌에 접근할수 없다는것을 알고 안내문을 빨리 알고싶어한다.
7) 페르소나 세부사항
- 기능 및 콘텐츠 : 페르소나의 동기와 비교해 봄(웹사이트의 당좌예금)
- 행동 : 사라는 홈페이지에서 '당좌예금 살펴보기'를 클릭하고 다양한 당좌예금 상품비교를 본다
- 인용 : 페르소나가 더 사람같은 느낌을 줌
8) 페르소나 생생하게 만들기
- 인구통계학 정보
- 기술 숙련도
- 신상정보
- 사진: 페르소나에 맞는 사진일 경우 쉽게 상상이 가능함

4. 사용성 테스트(Userbility Test)
1) 사용성 테스트의 개요
- 무엇을 위한 것인가?
   웹사이트 디자인에 대한 피드백을 얻기 위한 기술
- 테스트 계획은 산만해질 수 있으므로 명확한 방향이 필요함(정보설계로 갈거냐, UI만으로 갈거냐)
구체적인 목표를 설정해야 함
ex) 가진 사람이 사이트에 와서 자신이 앓고 있는 병에 관한 정보를 찾을 때, 그 정보를 어떻게 찾아가는지 확인하기 위해
2) 사용성 테스트의 인원 선정
- 개발할 사이트의 페르소나와 비슷한 유형의 사람들
- 컴퓨터 및 웹 사용에 미숙, 보통, 능숙한 사람의 비율을 조정하여 선별
- 대체적으로 테스트할 사이트를 처음 보는 사람들을 기준으로 함
3) 사용성 테스트의 산출물
- 워드 문서나 프로토타입
- 가공되지 않은 데이터나 간단한 보고서
- 녹음, 녹화기록, 관찰 결과 보고서, 개선점 도출 보고서 등
4)사용성 테스트의 사전/사후 설문
- 사전설문
   우리가 만들고 있는 사이트는 'fluffypuppies.com'입니다. 이 웹사이트는 어떤일을 하는 곳일까요?
   가족끼리 촬영한 비디오를 관리하기 위해 어떤 시스템을 사용하고 계십니까?
- 사후설문
   나는 이 웹사이트가 사용하기 쉽다고 생각한다.(1~7점)
5) 자유서핑 시간
- 테스터가 새로운 사이트에 적응할 시간을 줌
- 사용자가 처음으로 관심갖는 공간, 콘텐츠가 무엇인지 알아보는 테스트
6) 시나리오
- 점심시간에 의학 정보 찾아보기
주말에 당뇨병으로 진단받은 친구와 이야기를 나눴다...점심시간을 이용해서 당뇨병과 관련된 정보를 찾아본다. 점심시간이라 넉넉한 시간이 아니라 다 못봄..북마크를 할거냐 안할거냐...등으로 시나리오를 만든다.
7) 태스크(Task) 1
- 당뇨병에 대한 정보 찾기
   예상되는 행동    -> 메인페이지에서 '질병과상태' 클릭
호르몬 이상 클릭
   당뇨병 클릭
증상과 원인 클릭
   사후질문    -> 사이트에서 기대했던 당뇨병의 원인에 대한 정보를 찾을 수 있었습니까?
해당페이지에서 얻을 수 있다고 기대된 또다른 병은 무엇이었습니까?
8) 태스크(Task) 2
- 개인보관 페이지에 정보 저장하기
   예상되는 행동 -> 관심있는 글 클릭
   나중에 보기 위해 저장 클릭
저장된 글 목록 대화상자에 이름 입력
   사후 질문 -> 나중에 보기저장 기능을 어떤때에 사용하시겠습니까?

Having worked with personas before the method ever came to be known as personas there are, from my research and practical experience, three important areas that have to be considered: the data material, engagement in the personas descriptions, and buy-in from the organization which is part of the development process whether it is redesign or a development from scratch. This is the rationale behind my development of 10 steps to personas, an attempt to cover the entire process from initial data gathering to ongoing development.

In the following I will briefly outline the 10 steps. Any project that uses personas does not necessarily need to follow all 10 steps as long as the responsible party knows the consequences of skipping a step.

Step 1: Finding the Users
The initial step is to get hold of as much knowledge of the users as possible. The data can originate from several sources: interviews, observations, second hand information, questionnaires, reports, cultural probes etc. In my experience large companies have often a lot of information about the users, reports from marketing, call centers etc. these can in some extend substitute real life meetings with users, but they also create problems as they do not focus on the subject that the project is about. This might become visible in the next step.

Step 2: Building a Hypothesis
Working with personas is focusing on users in a certain context which originates from the project. Often companies have a certain way of talking about their users that does not take into consideration the different context the users might be in when using a website or a system. In a recent project for a national Danish authority concerning redesign of a web portal business reports to different governmental authorities, the national authority had a tradition for dividing Danish businesses into categories of size and trades. From interviews with staff in the call center and reading of several a hypothesis was formed.

The former division of businesses did not make sense in this project, as it does not matter which trade the one who has to do the reporting is in, what matters it seemed is how big the company is, and whether the persons who reports is employed within the company or a consultant of some sort. There had been a number of surveys performed, but none of these had this division in mind and had to be reread from the new perspective.

Step 3: Verification
In my experience the most difficult task in persona project are 'how to cut the cake' - coming from data to a decision of how may personas descriptions to include. This takes several of the 10 steps and involves more than a group of consultants or project members to just hand over some descriptions.

In 'Verification' the focus is on finding data that supports the initial patterns and at the same time supports the personas descriptions and the scenario writing. The persona method requires a certain kind of information that can help generate engagement in the descriptions and support scenario writing e.g. what does the users like ad dislike, what are their values, what are their attitudes towards the system/site, in what conditions will they use the system/site? When these data are collected do they then support or go against the initial data.

Step 4: Finding Patterns
My inspiration in this and the previous step originates from making sense of data in qualitative inquiries. The way you know that you are on the right track is when others can follow your argumentation and others can come to the same result. Therefore it is of importance to show the categorization to other team members, project partners etc.

Step 5: Constructing Personas
A crucial step is what to include in a personas description and how to avoid creating stereotypes. I have quite often seen personas descriptions that either depict super humans or stereotypes that is difficult to engage in. In this phase you must remember that the whole purpose of personas is not to describe users as such, but to create solutions that use the needs of the persona as a starting point.
Drawing on knowledge from fictional writing of characters 5 areas need to be present in the description, not mentioned specifically, but possible for the reader to deduct from the description.

- Body (a photo or a description of how the person looks creates a feeling of the person as a human being, posture and clothing tells a lot about the person)
- Psyche (we all have an overall attitude towards life and our surroundings which also influence the way we meet technology e.g. is the persona introvert or extrovert)
- Background (we all have a social background, education, upbringing which influence our abilities, attitudes and understanding of the world)
- Emotions and attitudes towards technology and the domain designed for
- Personal traits. This one is tricky, in fictional writing there is a distinction between flat characters and rounded characters. The flat character is characterized by having only one character trait which is reflected in all actions the character does and creates a highly predictable character close to the stereotype. The flat character is difficult to engage in. The rounded character has more than one character trait, is not predictable and easier to engage in. When writing personas is becomes essential to avoid the stereotype and create descriptions that the project team members can engage in. Therefore it is advisable to look for information that repeats the same trait. In a case I had, the persona to be described liked to feel in control, from this the team members writing the description made her work for the tax authorities, this came to reflect her attitude to life, she became overweight and with few friends. For them the information of being in control created a negative attitude towards the persona that was repeated in all information.

The fifth step is also a step that can ensure that can enhance buy-in. In my experience it is few organizations who allow for team members to be part of the writing process instead they use consultants or the usability department to write the descriptions. The personas method should rather be perceived as a process where everybody should understand how the descriptions came about and what they can be used for. If you allow different team members to be part of the writing process they feel ownership for the personas. They can be rewritten be a single person to ensure homogeneity in writing and presentation, but it pays off later to include more in the writing process or as we did in a project, to let the participant choose the pictures for the personas.

I am fully aware that not everybody can be part of the process, newcomers arrive, a row of companies might be involved, but if the personas are not disseminated to participants they are not worth anything. It is not only the personas that need to be distributed to everybody, but also the data behind (the foundation document as Grudin, Pruitt, Adlin calls it) and not least how and for what you are to use the personas. Many projects forget to inform and teach developers and designers how to use the personas, how to think in scenarios or how to use them in the use-cases.

Step 6: Defining Situations
As mentioned earlier the real purpose of the personas is to create scenarios from the descriptions. This step is a preparation for the scenarios where it is described in which situations the persona will use the system/site or which needs the persona has that will lead to a use situation. Each need or situation is the beginning for a scenario.

Step 7: Validation and Buy-in
To ensure that all participants agree on the descriptions and the situations two strategies can be followed: ask everybody their opinion and let them participate in the process. Often the persona method is viewed as mean for communication users to developers and others, but is as much a process that ensures a user-centered development. Having a process view helps create sessions where as many stakeholders as possible can be involved in the developing the personas and in using them for design.

Step 8: Dissemination of Knowledge
I am fully aware that not everybody can be part of the process, newcomers arrive, a row of companies might be involved, but id the personas are not disseminated to participants they are not worth anything. It is not only the personas that needs to be distributes to everybody, but also the data behind (the foundation document as Grudin, Pruitt, Adlin calls it) and not least how and for what you are to use the personas. Many projects forget to inform and teach developers and designers how to use the personas, how to think in scenarios or how to use them in the use-cases.

Step 9: Creating Scenarios
As mentioned earlier, personas are nothing in themselves, it is when a persona enter a scenario they prove to be valuable. A scenario is like a story, it has a main character (the persona) a setting (somewhere the action takes place), it has a goal (what the persona wants to achieve), it has actions that lead to the goal (interactions with the system/site/device), and -not least- it has obstacles that blocks the way to the goal. I have seen quite a number of what I call happy scenarios, where a device solves all problems. Try to read this description of Mrs Tahira Khan and how she overcomes her diabetes and you will see what I mean. It is not a very realistic or convincing example that a 65-year old woman, who recently traveled to UK, who has undiscovered diabetes, hardly any understanding of the English language and relatively poor literacy in her own language overcome her diabetes with an electronic device.

Step 10: Ongoing Development
Lastly I recommend updating information on the personas. This can be done if user tests suddenly show new results or if something changes in the personas environments. It is crucial that not everybody is able to change the information, but knows whom to contact. I often recommend having a personas ambassador, who looks into the descriptions now and then, and who project participants can contact if they find irregularities in the descriptions. And as Adlin and Pruitt recommend in 'The Personas Lifecycle' to let the personas die, when they have outlived their purpose.

http://www.hceye.org/HCInsight-Nielsen.htm

bobozzang .

퍼소나

2 POSTS

[3강] 퍼소나/사용성 테스트

Please leave a comment.

Ten Steps to Personas

Please leave a comment.

bobozzang.

퍼소나

2 POSTS

[3강] 퍼소나/사용성 테스트

Please leave a comment.

Ten Steps to Personas

Please leave a comment.

bobozzang .