잘만든 Concept Model

컨셉 모델 만들어보라 그러면 꼭 flow를 그려요.

관계를 정의해 보지 않아서 그런 것 같아요.

flow를 그리다 보면 모두들 이런 문제가 발생하더군요.

“A와 같은 케이스에는 달라지는데 이건 어떻게 표현하지?”

음.. 굳이 다 표현안해도 되요.

flow는 서비스의 메인 흐름과 그와 관계된 흐름들만 보여주면 됩니다. 그 흐름 속에 영향을 미치는 요소들과의 관계를 잘 표현할 수 있으면 되구요. 대표적인게 그 유명한 Flickr 컨셉모델이죠.

아래 컨셉모델도 비슷한 유형인데 못보셨을 것 같아 공유합니다.

DCERP_concept_sm

(이미지 출처 : https://dcerp.rti.org/)

어떤 산출물을 만들 때, 왜 그것을 만들고 어떤 목적으로 사용 할 것인지를 먼저 생각하는게 중요한 것 같습니다.

Advertisements

Concept Model – 머릿속의 생각들을 가시화 시키는 기초작업

저는 UX를 하는 사람들은 <애매한 것을 정의>해 주는 사람이라고 늘 말하고 다닙니다.

<사용자>를 정의하고, <아이디어>를 구체화 하고, <여러 생각들>을 정리하고, <방향성>을 정의합니다.

(현재 우리나라에서의, IT산업에서의 UX만 볼 때) 디자인 작업을 하기 위한 프로세스에서는 수많은 생각들을 어떻게 가시화 시켜 눈 앞에 보여주느냐가 중요한 문제가 되었습니다. 그저 디자인이 나올 때 까지 기다렸다가 메인시안 뽑고 뒤집히고 또 뽑고 뒤집히고 그러다보면 <상대에게 매력을 주는 핵심 포인트 = 컨셉 = 차별화전략>이 사라져 버리고.. 시간에 쫓겨 디자인은 정해져 버립니다.

이런 디자인을 하려면 사실 고민하는 시간 자체가 아깝죠.

“무엇을 만들겠다(서비스 기획)”라는 것과, “어떻게 만들겠다(아이데이션)”을 어느정도 마무리지으면,  그 생각들이 어떤 구조로 형성되는지 그려내는 것이 컨셉모델입니다.

Image

(이미지 출처 : http://www.jonkolko.com/writingInfoArchAsSynthesis.php )

Concept Model은 어떻게 그리나요?

컨셉모델은 생각들을 구성하는 요소 중 “명사”에 해당하는 Entity 와 “동사”에 해당하는 Relation 으로 구성됩니다.

1. Entity들을 모두 뿌려놓고, 친화도(Affinity Diagram) 작업을 통해 묶을 수 있는 Entity는 최대한 묶어둡니다.

2. 그 중 key가 되는 Entity는 친화도가 높아도 별도로 떼어놓습니다. (이 놈이 묶여버리면 핵심가치를 놓칠 수 있어요)

3. 각 Entity들을 Relation들로 연결시킵니다.

4. Entity의 중요도로 크기, 색상등을 결정하여 조절하고, Relation의 흐름안에 거쳐 지나가는 Entity들은 Relation 자체를 넓은 화살표로 표현하여 그 과정에 포함시킵니다.

5. 뚫어져라 보면서 더 좋게 다듬습니다….. (우리가 만들려는 서비스가 맞는지, 더 명확히 표현할 수 있는지..)

컨셉모델은 왜 만드는가?

이렇게 만들어진 컨셉모델은 개발자에게 엄청난 양식이 됩니다.

컨셉모델 작성법은 실제로 개발의 DB구조를 설계할 때 기초방법과 굉장히 흡사하며, 실제 나온 Concept Model을 참고하여 ERD(뭔지는 검색해 보삼)를 그려내기 쉽기 때문입니다. 개발자와의 커뮤니케이션이 이 Concept Model 하나로 한 방에 해결됩니다.

기획 초기에 Concept Model을 그려놓고 시작하는 것이 협업자간 커뮤니케이션에 엄청 큰 도움이 되는 이유가 여기에 있습니다. (설득이 시간이 엄청 줄어듭니다.)

자, 이제 사용자를 정의할 때입니다. (물론 서비스 기획 단계에서 사용자가 어느정도는 정의되어 있을 겁니다. 그래서 Concept Model을 먼저 작업합니다. – 물론 서비스 기획 단계의 사용자 정의는 Ethnography를 통해 뒤집힐 것입니다. )

to be continue…

Why Create Conceptual Model?

컨셉모델링, 왜 필요한가?

신규 서비스/제품을(를) 기획하거나 기존에 있던 서비스/제품의 리뉴얼이 필요할 때, To-Be 모델의 사용자가 어떻게 사용할지를 선과 도형으로 표현하곤 한다. 그것을 사람들은 ‘Conceptual Model’ 혹은 ‘Information Surfacing’ 등으로 부른다. 그 내용을 보면 사용자들이 어떻게 사용할 것인지, 어떤식으로 사용할 수 있을지 누가봐도 이해할 수 있어야 한다. 그리고 더 좋은 모델링은 왜 사용하는지도 표현이 되어있는 것이다.

컨셉모델을 그리는 것의 이유는 바로 여기에 있다. 컨셉모델을 보며 프로젝트에 관여한 관리자, 기획자, 디자이너, 개발자, 테스터 그리고 고객이 한 방향을 바라보게 해야한다. 커뮤니케이션의 기본은 ‘이해’에서 출발하듯 컨셉모델이 ‘이해의 도구’가 되어 같은방향으로 커뮤니케이션을 할 수 있도록 하는 것이다.

이미지 하나를 보고 만들고자하는 서비스나 제품 방향이 이해가 간다! 사용자가 어떻게 사용할지 알 수 있다!면 이미지 한 장 그로써 충분하다. 반드시 선이나 도형이 아니어도 좋다는 것이다.

Flickr concept model

Flickr Concept Model(Image:Jounce)

This-holographic-tablet-makes-your-desktop-3d-70d45a37cc

The zSpace(Image:Mashable)

Flickr Concept Model로 본 구성

컨셉모델하면 Flickr의 컨셉모델을 대표로 꼽을 수 있을정도로 좋은 예시로 사용된다. 위에 첨부된 이미지를 통해서도 볼 수 있듯이 한 페이지를 통해 이 서비스가 어떤 목적이고 어떠한 흐름으로 움직일 것인지를 이해할 수 있다.

‘A Flickr user takes Photos of a Subject’으로 상단에 이 서비스의 사용목적?을 알 수 있다.   그리고 Flickr/Photos/Subject의 각 객체가 다른 사용자 그룹이나 컨텐츠에 어떻게 녹여지고 사용될 수 있는지 그 아래에 텍스트/이미지/도형/선을 이용하여 풀고있고, 그 흐름들이 유기적으로 얽혀있다.

중요한것은 각 흐름에서 사용자 위치와 사용가능한 행동이 자세하게 묘사되어 있다는 점이다. 컨셉모델이라고 불리는 여러가지 예시들을 보면 이러한 자세한 설명이 명시되어 있지 않은 것들이 많다. 그럴 경우, 프로젝트 관련자들의 커뮤니케이션에 혼란을 가져올 수 있다. 만약, 컨셉모델을 그려보고 싶거나 그려야 한다면  Flickr와 유사서비스의 컨셉모델을 이 Flickr컨셉모델을 참고하여 그려보고 본인의 서비스를 만들어 보면 많은 도움이 될 것 같다.

concept model

컨셉모델에 대한 이런저런 검색과 책을 보면서 ‘개념’이라는 말에 대해 생각을 해보았다.
흔히 사람에게 개념이 없다라고 하는것도 컨셉모델에서 말하는 개념과 동일하게 쓰일까?
기본적인 사람이 갖춰야 할 개념 그리고 상황에 대한 개념 나는 컨셉모델에서의 개념도 동일하게 봐도 괜찮지 않을까? 라는 생각이 들었다.

우리 서비스의 개념을 이해하기 위해 만드는 컨셉모델 모두다 이해하고 공감하는 서비스..
개념..우리가 만들고자 하는 서비스에 개념을 명확하게 끄집어내어 정리해보자.

기본적인 정의들만 정리해보았다.

[ concept model ]

사전적 의미
– 추상적인 개념의 관계를 보여주는 그림. 웹 사이트의 다양한 측면을 설명하기 위해 다양한 상황에서 콘셉트 모델링 기법을 적용
– 콘셉트 지도, 친화도 다이어그램이라고도함.
– 다른 다이어그램의 포맷과 같이 선으로 연결된 도형들로 이루어져있음.

컨셉모델 소개
: 노드 도형은 컨셉, 선은 컨셉사이의 관계

사이트맵과 컨셉모델과의 차이점
– 모든 종류의 관계를 보여준다
– 시작과 끝이 불명확하다.
– 사이트 기반 컨셉에 대한 이야기를 전달한다. 이는 콘텐츠 카테고리 일수도 있고 아닐수도 있다.
– 노드의 의미가 훨씬 광법위하다.

컨셉 모델의 정의
– 어렵고 개념적인 생각을 위한 모델
– 간결하게 서비스의 개념을 전달할수있다.
– 다양한 정보를 이해하기 위해서 concept model 을 만듬.
– 추상적인 개념을 전달

컨셉모델 작성에 대한 자세한건 책을 통해 습득한 것들이라 주저리주저리 여기에 쓰긴.. 쫌…