다행히도 늦지 않고 강의를 들으러 올 수 있었습니다.




=========================   1   ==========================


(09:00 ~ 10 : 11)


강사소개.

현 카카오 어느 디자인팀의 파트장을 맡고 계셨습니다.


UX가 UI를 포함하는 개념이며 UX는 어떤 디자인이나 개발에서도 핵심적으로 고려해야 할 개념이라고 설명을 해 주셨습니다.



우선 제가 이해를 한 방향으로 정리를 하면 UI는 인터페이스에 대한 디자인 즉 외적인 요소, 보여지는 요소로 이해를 하였으며, UX는 만족도, 가치와 같은 느낌으로 해당 제품이나 서비스를 통해서 느껴지는 전반적인 인상이라고 이해를 하였습니다.


또한 UI와 UX의 관계를 보면 UX가 UI를 포함하는 개념으로 이해를 하는 것과 또 달리 그 두가지가 서로 일부를 공유하는 (교집합을 갖는) 식으로 이해를 하는 두가지의 관점이 있다고 소개를 해 주셨습니다. 또한 좋은 UI와 좋은UX의 관계는 UI가 좋다고 꼭 UX가 좋은것은 아닐 수 있다는 것과 UI가 디자인적인 요소로 아름답거나 뛰어나지 않더라고 좋은 UX를 줄 수도 있습니다.

( 지극히 주관적인 좋은 디자인UI의 예 )             ( 좋은 디자인이 주는 좋지않은 UX)

자동차로 비유를 하자면 저는 람보르기니 자동차를 굉장히 좋아합니다. 디자인적인 요소로 훌륭하다고 생각합니다. 하지만 TV프로그램에서 승차감과 전반적인 운행에 관한 소개를 본 적이 있었는데 일반적인 세단보다 차체가 낮아서 탑승이 불편하고 승차감도 일반 세단에 비해 훨씬 거칠었다면서 좋은 UX를 느끼지 못한 동승자(여자분)의 인터뷰를 봤었습니다.


UI는 Value를 구현하기 위한 도구라고 설명을 해 주셨으며 그 가치는 물론 사용자가 필요하고 추구하고 얻고싶어하는 것 입니다. 또한 디자인이 사용자 요구를 반영하지 못하여 나타난 사례들도 보여주셨습니다.


UI는 Value를 구현하는 도구라고 하면 UX는 Value 그 자체라고 설명을 해 주셨습니다.


그 후에는 여러가지 제품 기획 및 생산에 관한 주기(life cycle?) 과정에 대해서 몇가지 소개를 해 주셨습니다.


UCD

GDD

LEAN

AGILE

LEAN + AGILE


 


=========================   2   ==========================


( 10 : 23 ~ 11 : 18 )


두번째 시간은 UX/UI 이론과 실습이라는 주제로

이해하기 / 디자인하기 / 테스트하기 중에

이해하기에 대한 부분을 진행하였습니다.

이 이해하기라는 주제의 주어는 사용자, 즉 사용자를 이해하는 것에 대한 내용입니다. 우선 사용자를 이해하는 방법으로 Research에 대해 자세하게 설명을 해 주셨습니다.

Research! (손으로 적은 노트에 철자를 틀리게 몇번 적은 것 같습니다...)

우선 Research에 대해서 개념정리 및 소개를 해 주셨습니다. Research는 도구이고 맥락을 이해하는 것이 중요하다고 하셨습니다.

Research는 사람들이 좋아하는 것을 묻는것이 아니며 정치적 도구가 아니라고 하셨습니다. 정치적 도구에 관한 부분을 Research결과의 일부분을 본인의 의도에 맞게 처리하여 보고를 하거나 하는 식으로 사용을 하여 전체적인 Research결과와 다르게 해석을 하거나 해석을 할 수밖에 없도록 만드는 것 그리고 그러한 일을 하여 자신의 업무에 힘들 더하기 위한 여러가지 못된 짓(?)을 이야기 해 주셨습니다.

Research에 대한 5가지 오해가 있다고 하셨으며 5가지 하나하나 소개를 해 주시고 그런 오해들을 없에고 이해할 수 있도록 설명 해 주셨습니다.

1. 10명으로는 아무것도 알 수 없다

10명으로는 선호도 조사를 할 수는 없습니다. (물론 전체 그룹원이 10명 혹은 그에 근접하면 가능합니다만...) 하지만 고객 혹은 대상 한사람 한사람의 세세한 요구사항과 사용패턴을 알아볼 수는 있습니다.

2. 사용자에게 물어봤자 대답은 뻔 하다

사람의 말로 표현되는 요구사항은 5%에 불과하다는것이 강의자료에 적혀 있습니다. 즉, 사용자에게 Research를 하는 동안에 말로 드러나는 요구사항 뿐 아니라 관찰을 통해서 Research대상이 드러내지 않은 95%의 요구사항을 알아 낼 수도 있고 사용자의 행동패턴도 파악할 수 있습니다.

3. 리서치할 시간이 없다.

Research를 하는데에도 역시 시간이 필요하다. 시간 뿐 아니라 금전적 비용 또한 어느정도 발생할 수 있습니다. 하지만 프로젝트 도중에 문제가 생기는 것을 Research를 통해서 예방할 수도 있고 그러한 위험을 예방하여 전체적인 시간을 단축해주는 역할을 합니다.

또한 프로젝트의 방향성을 잡아주는 역할을 하여 방향을 명확하게 잡아서 이것 도한 전체 프로젝트의 진행에 위험을 낮추고 시간을 단축시킬 수 있는 요인이라고 생각합니다.

4. 전문가도, 예산도 없다.

Research는 Research 프로세스와 인터뷰 방법만 익히면 누구나 할 수 있습니다.
또한 예산이 전혀 들지 않는것은 아니지만 전문적인 Research도구나 장비가 필요하지 않다면 큰 비용이 들지는 않습니다.

5. 이미 문제점은 알고 있다.

그렇다면 정말로 알고 있는가에 대한 질문을 돌려줘야 할 것 같습니다. 또한 문제점을 잘 알고 있는것과 사용자를 잘 아는 것은 별개의 문제입니다.

또한 사용자를 테스터와 같은것이라고 생각하면 안됩니다. 테스터는 제품의 테스트에 협조적이고 어느정도 관심이 있는 사람들이지만 실제로 제품을 판매 혹은 제공해야 할 전체적 대상인 사용자를 베타테스터처럼 생각하면 완성도가 떨어질 수 있으며 그들의 호평을 얻기는 커녕 사용도 한번 재데로 해보지 않을 수 있습니다.


정리 후에는 Research Process에 대해서 설명을 진행 해 주셨습니다.


=========================   3   ==========================


( 11 : 35  ~ 12 : 00)



실습 소개


1. 조별로

2. 자주 사용하는 한가지 모바일 서비스 선택하지

3. 인터뷰 진행자, 인터뷰 참여자, 관찰자 나누기 (역할 배분)

4. 주제맵 작성 (어떤 질문을 할 것인가)

5. 진행자가 질문하고 참여자가 경험을 토대로 이야기, 관찰자는 노트에 기재하기

6. 관찰자가 간단히 요약하고 마무리 (Pain point : 개선이 시급한 부분 정의)


문제점을 발견을 해야 그 이후에 실습이 진행이 될 수 있습니다. 불편사항 위주로 결과를 얻을 수 있도록 할 것.


개선이 시급한 부분을 최소 1개에서 최대 3개정도를 우선순위를 고려하여 정리를 할 수 있도록 실습하기를 바라셨습니다.


인터뷰시간은 20분정도,


주제 지도에는 질문하고자 하는 주제를 적습니다. 서비스에 따라서 주제 지도의 내용은 많이 서로 다를 수 있습니다.


우리 조는 Polaris office라는 앱을 가지고 하기로 했는데 써본적도 없고.... 거기 개발자 한명이 또 답변을 잘 할 것 같다는 느낌도 들지 않지만 조의 평화를 위해 굳이 말을 하지 않았습니다. 실수와 실패를 통해서도 배울 수 있는 강의 시간이기 때문입니다. 아까 분명 테스트를 하거나 의견을 구하고 리서치를 할 때 내부의 사람이 아닌 사용자를 대상으로 하여야 보다 더 객관적이고 내부에서 보지 못한 문제점들을 발견할 수 있다는 강의 내용이 있었지만 다들 잊으신 것 같기도 합니다.





=========================   4   ==========================


(13 : 05 ~ 14 : 11)


인터뷰 실습을 진행~


1~5조의 각각 선정 App을 먼저 소개 해 주셨습니다.


우리조는 2조로 Polaris office라는 App을 대상으로 선정하였습니다.


13:10 ~ 13:30 까지 인터뷰를 진행하기로 하였습니다.


13:30 ~ 13:40 까지 인터뷰 내용을 정리하기로 하였습니다.



인터뷰 후 각각 조들의 인터뷰 후 발견한 문제점을 발표하였고 인터뷰 중간에 강사님께서 각 조별 인터뷰를 관찰하고 각 조의 장점 및 단점이나 특이한 점을 같이 소개해주셨습니다.


저희 팀에서도 인터뷰를 진행하면서 느끼기 시작 한 것이 인터뷰진행자의 질문에 참가자가 점점 개발자의 입장에서 이야기를 하면서 진행자보다 더 많은것을 알고 있는 경우가 있어서 의아 해 했습니다.




=========================   5   ==========================


(14 : 21 ~ 15: 04)


이해하기 / 디자인하기 / 테스트하기


디자인 하기


약간 지루할 수도 있는 부분이라는 이야기로 강의를 시작하셨습니다.








=========================   6   ==========================

쉬는 시간 10분여를 잤는데 개운했지만 약간 멍 해졌습니다.

(15 : 20 ~ 16 : 01)




=========================   7   ==========================


(16 : 10 ~ 17 : 00)

디자인하기 실습에 관한 설명을 해 주셨습니다.


- 구조와 동선그리기


1. 조별로 진행을 할 예정

2. 앞선 실습의 서비스를 이용하여

3. 포스트잇을 활용하여 A4용지에 정보구조 그려보기

4. 주요 동선을 하나 잡아 플로우 그려보기

5. 정리하고 마무리

(pentaxzs  카톡아이디로 결과물 사진 보낼 것)


1) 정보구조 만들어 보기

(개인별 A4용지 사용)



2) 플로우 차트 그려보기 

플로우 차트를 통해서 스케치를 할 것입니다. 포스트잇 하나가 하나의 페이지를 의미하며 화살표 아래의 설명은 Action을 의미합니다.

page와 feature를 구분하는 것이 필요할 것



실습을 조별로 진행을 하며 다시한번 확인을 했지만 제가 생각 한 것과 팀의 생각이 다소 차이가 있는것을 확인 했습니다. 심지어 해당 App의 개발자 분 또한 뭔가 저와는 다르게 생각을 하여 우선 지켜보았습니다. 또한 강사님의 실습 내용을 잘 못 이해한 것 같아서 실습 중 조금은 답답함을 느끼기도 했지만 새로운 App을 사용해보고 분석 해 보는것에 대해 고려해 보면 도움이 될 수 있는 시간이었습니다.


=========================   8   ==========================

팀별 회의를 하면서 뭔가 쉬는시간이 아닌 쉬는시간이 길어지기는 했습니다.


(17 : 10 ~ 18 : 00)


저희 팀을 제외한 다른 팀은 뭔가 시간이 더 필요한지 이전 시간에 이어 토의를 하고 있었고 유일하게 저희 팀만 이전 시간에 강사님에게 저희 순서도와 정보구조 만든것을 촬영하여 보냈습니다.


우선 선정한 App에 대해서 전반적으로 잘 알지 못한 것을 보면 처음 실습때부터 App을 잘 못 골랐던 것 같습니다. 뭔가 다른 팀하고 겹치지 않는 것 또한 중요하지만 분명히 팀원들이 다 아는 앱을 골랐어야 했다고 생각을 합니다.







테스트하기 이론쪽은 다음주에 진행을 할 예정이라고 하셨습니다.

그리고 오늘 나머지 시간에는 스케치하는것에 관련된 수업을 진행한다고 하셨습니다. 연필과 지우개를 나누어 주시면서 수업을 준비하셨습니다.


pop라는 app을 소개 해 주셨는데 정말 유용하다고 생각이 되어 이것에 관련된 내용은 추후에 다른 글로 도구 관련된 부분에 추가를 하도록 하겠습니다.

+ Recent posts