티스토리 뷰
학습목표
다양한 아이디어 발상 기법을 알아보고 이를 UI/UX 디자인 실무에 적용 해 보자.
아이디어의 정의 - 새로운 경험을 디자인한다.
아이디어의 뿌리는 철학적인 개념인 **이데아(Idea)**에서 비롯된 것으로, 이는 우리의 의견, 신념, 암시와 같은 사고의 기반이 된다.
최근에는 아이디어가 마케팅 활동을 충실히 하고 발전시키는 창의와 착상의 기반으로 알려져 작업 방법, 설비, 광고, 판매, 경영 활동, 제품 개발 등 시장 활동 전반에 걸쳐 결정적인 역할을 하고 있다. 그런데 막상 제품이나 서비스를 제공하기 위해 새롭고 독특한 아이디어나 콘셉트를 떠올리려 하면 막연하게 느껴질 때가 많다.
새로운 아이디어라고 해서 반드시 무無에서 유有를 창조해야 하는 것은 아니다.
많은 사람들이 아이디어가 완전히 새로운 것, 즉 "무에서 유를 창조하는 것"이라고 생각할 수 있지만, 실제로는 기존의 아이디어를 조금 더 개선하고 발전시키는 것만으로도 충분히 가치 있는 아이디어가 될 수 있다. 새로움은 반드시 완전히 새로운 것을 창조하는 것이 아니라, 기존의 것을 재해석하고 나아지게 하는 과정에서 생겨날 수 있다.
아이데이션(Ideation)
- “해결해야 할 문제에 대한 좋은 아이디어!”
- 즉, 현재보다 나은 아이디어(해결 방법)를 이해관계자들이 함께 찾아 나가는 과정 (아이디어 촉발과 증폭현상 유도)
Ideation은 새로운 아이디어를 창출하는 과정을 의미하며, 이는 문제 해결을 위해 창의적인 사고를 유도하는 단계이다. 아이데이션은 보통 디자인 씽킹 프로세스에서 두 번째 단계로, **공감(Empathy)**을 통해 사용자 문제를 파악한 후, 그 문제를 해결하기 위한 다양한 아이디어를 도출하는 과정에서 사용된다.
어떻게 하면 많은 이해관계자들이 협력하여 좋은 아이디어를 찾을 수 있을까요?
디자인 씽킹에서는 다양한 사람들이 함께 좋은 아이디어를 찾을 수 있도록 여러 가지 방법론을 제시하고 있습니다. 지금부터 그 다양한 아이데이션 방법론을 알아보겠습니다.
"HMW"로 아이디어 촉진 질문을 구체화하라!
How Might We ~?
- How Might We ~?(어떻게 하면 우리가 ~ 할 수 있을까?)”
- 디자인 씽킹에서 아이디어를 촉진하기 위해 사용하는 정형화된 문장 구조
Airbnb의 사용자 경험 개선:
- 문제: Airbnb는 처음에 사용자가 개인 소유의 집이나 방을 공유하는 서비스에 대한 신뢰감을 느끼지 못하는 문제에 직면했다.
- HMW 질문: "How might we create trust between hosts and guests so that they feel comfortable staying in someone’s home?"
- 결과: 이 질문을 통해 Airbnb는 리뷰 시스템과 프로필 인증 시스템을 도입했다. 이를 통해 사용자가 서로에 대한 신뢰를 구축할 수 있었고, 서비스는 더 많은 사용자들에게 신뢰를 얻게 되었다. 결국, Airbnb는 세계적인 성공을 이루었다.
세렌디피티 효과(Serendipity Effect),
**세렌디피티 효과(Serendipity Effect)**는
예상하지 못한 상황에서 뜻밖의 발견이나 좋은 결과를 얻는 현상을 의미한다. 이 용어는 18세기 영국 작가 호러스 월폴(Horace Walpole)이 동화 '세렌디프의 세 왕자들'에서 영감을 받아 처음 사용했다. 이 이야기에서는 세 왕자들이 우연히 문제를 해결하거나 중요한 발견을 하게 되는 내용이 등장하는데, 이를 바탕으로 뜻하지 않은 순간에 얻는 행운이나 중요한 발견을세렌디피티라고 부르게 되었다.
페니실린의 발견
: 알렉산더 플레밍이 페니실린을 발견한 것은 대표적인 세렌디피티의 예이다. 그는 박테리아 연구를 하던 중, 우연히 곰팡이에서 항생 물질을 발견하게 되었다.
포스트잇
: 3M에서 접착제가 개발되는 과정에서, 원래 목표와는 달리 쉽게 떼어낼 수 있는 접착제가 만들어졌고, 이로 인해 포스트잇이 탄생하게 되었다.
디자인 씽킹은 종종 세렌디피티 효과(Serendipity Effect),-완전한 우연으로부터 중대한 발견이나 발명이 이루어지는 것을 말하며, 디자인 씽킹 과정에서 세렌디피티 효과를 일으키기 위해 필요한 공식은 아래와 같다:
“올바른 질문(Right Question) + 올바른 아이디어(Right Idea) + 올바른 해결책(Right Solution) + 적합한 참여자(Right Person) + 적합한 시간(Right Time) + 적합한 시장(Right Market) = 디자인 씽킹 세렌디피티 효과(Design Thinking Serendipity Effect)” 이를 위해서 가장 먼저 해야 할 일은 올바른 질문을 만드는 일입니다.
세렌디피티 효과는 우연한 발견이지만, 그 배경에는 끊임없는 탐구와 열린 사고가 필요하다. 이 공식은 디자인 씽킹에서 세렌디피티 효과를 최대화하기 위한 기반을 형성한다. 특히, 이 모든 과정의 시작은 올바른 질문을 만드는 것에서 시작한다. 질문이 명확하고 구체적일수록, 문제 해결을 위한 혁신적인 아이디어와 해결책을 찾는 데 큰 도움이 된다.
아이데이션 5단계
아이데이션(Ideation) 5단계는 창의적 아이디어를 도출하는 과정에서 효과적으로 사용할 수 있는 단계별 방법론이다.
상상력을 자극할 수 있는 HMW(How Might We) 문장이 준비되었다면, 아이디어 확산 수렴을 위해 그림 “아이데이션 5단계
(01. 문제 정의하기 → 02. 상상력을 자극하는 질문하기 → 03. 떠오르는 것을 생각하고 기록하기 → 04. 아이디어 정리하기 → 05. 탁월한 아이디어 선정하기)”에 따른 다양한 방법들을 수행할 수 있습니다. 각 단계를 상황에 따라 용도와 목적에 맞게 사용하면 좋은 아이디어를 찾아낼 수 있죠.
이를 위해서 가장 먼저 해야 할 일은 올바른 질문을 만드는 일입니다. 디자인 씽킹에서는 구조화된 문장을 통해 질문을 구체화할 수 있습니다. 이때, 디자인으로 해결해야 할 문제(Design Challenge)는 먼저 고객중심 공감 사고(POV: Point of View)로 정의해야 하죠. 고객중심 공감 사고 문제 정의는 구조화된 평서문의 형태로, “누구의 문제인가?”를 정의하는 데 집중할 수 있도록 수렴적 사고를 유도하기 때문입니다.
1. 문제 정의하기:
- 한 음식 배달 앱에서 고객들이 결제 과정에서 불편함을 겪는다는 피드백을 받았다고 가정한다. 이때 문제 정의는 "어떻게 하면 결제 과정을 더 간단하고 직관적으로 만들 수 있을까?"라는 식으로 설정할 수 있다. 이를 통해 고객의 불편함을 해결할 수 있는 명확한 문제를 정의한다.
2. 상상력을 자극하는 질문하기 (HMW):
- 문제 정의 후, 상상력을 자극하는 HMW(How Might We) 질문을 만들어낸다. 예를 들어, "어떻게 하면 사용자가 3번의 클릭만으로 결제를 완료할 수 있을까?" 같은 질문을 통해 다양한 해결책을 상상할 수 있도록 유도한다. 이러한 질문은 창의적인 해결 방안을 찾는 데 도움이 된다.
3. 떠오르는 것을 생각하고 기록하기 (브레인스토밍):
- 팀이 모여 다양한 아이디어를 제시하고 브레인스토밍을 통해 모든 생각을 자유롭게 기록한다. 예를 들어, 한 팀원이 "QR 코드 결제 시스템 도입"을 제안하고, 다른 팀원은 "앱에 저장된 카드 정보를 자동으로 불러오는 기능"을 제안할 수 있다. 이 단계에서는 아이디어의 양을 중요시하며, 자유롭게 다양한 해결책을 탐구한다.
4. 아이디어 정리하기:
- 아이디어를 그룹화하고 관련된 아이디어를 묶어 체계적으로 정리한다. 예를 들어, "간편 결제"에 대한 아이디어를 묶고, QR 코드 결제, 간단한 클릭 절차, 자동 카드 정보 불러오기 등으로 분류한다. 이 과정에서 실행 가능한 아이디어와 개선이 필요한 아이디어를 구분한다.
5. 탁월한 아이디어 선정하기:
- 최종적으로 가장 혁신적이고 실현 가능한 아이디어를 선정한다. 예를 들어, 팀은 QR 코드 결제와 자동 카드 정보 불러오기 아이디어를 결합해 하나의 솔루션으로 선택할 수 있다. 팀 내에서 Dot Voting과 같은 기법을 사용해 팀원들의 의견을 모아 최종 아이디어를 결정한다.
아이데이션의 각 단계는 문제를 창의적으로 해결하기 위해 구체적이고 체계적으로 진행된다. 이 과정은 문제 정의에서부터 탁월한 아이디어 선정까지의 흐름을 효과적으로 관리하며, 디자인 씽킹 프로세스의 중요한 부분을 형성한다.
아이디어 도출을 방해하는 10가지 정신적 장애물
- 단 하나의 정답을 찾으려는 것: 다양한 가능성을 탐구하지 않고, 정답이 하나라고 믿는 사고방식이 창의성을 제한한다.
- 지나친 논리적 사고: 논리적인 사고는 중요하지만, 때로는 그것이 창의적인 사고를 억제할 수 있다. 아이디어 도출 단계에서는 논리보다 자유로운 사고가 필요하다.
- 융통성 없이 규칙만 따르는 것: 규칙에 얽매이면 새로운 아이디어를 떠올리기 어렵다.
- 지나친 현실적 사고: 모든 것이 가능하지 않다는 현실적인 사고는 아이디어의 폭을 좁힐 수 있다.
- 재미를 즐길 줄 모르는 태도: 창의적 과정에서 유연하고 즐거운 태도가 필요하다.
- 지나친 전문화: 너무 전문적인 관점에 갇히면 다른 관점에서 문제를 보는 능력이 제한된다.
- 애매모호한 것의 회피: 명확한 답을 찾으려 하고, 애매한 상황을 피하려는 경향은 창의적인 해결책을 찾는 데 방해가 된다.
- 바보처럼 보이는 것에 대한 두려움: 새로운 아이디어를 제안할 때, 비판받거나 바보처럼 보일 것에 대한 두려움이 창의성을 억제할 수 있다.
- 실수하기 싫어하는 태도: 실수를 두려워하면 새로운 시도를 하지 않게 된다.
- 자신이 창의적이지 못하다고 믿는 것: 창의성에 대한 자신감이 없으면 새로운 아이디어를 도출하는 것이 어렵다.
콘셉트 모델(Concept Model)- 애매한 것을 정의
콘셉트 모델(Concept Model)은 추상적이고 애매한 개념을 명확히 정의하고, 그 관계를 시각적으로 표현하는 데 중요한 도구이다.
- “무엇을 만들겠다(서비스 기획)”라는 것과, “어떻게 만들겠다(아이데이션)”을 어느 정도 마무리 지으면, 그 생각들이 어떤 구조로 형성되는지 그려내는 것
- 신규 제품 또는 서비스를 기획하거나 기존에 있던 제품 또는 서비스를 리뉴얼 할 때모델 사용자가 어떻게 사용할지를 선과 도형으로 표현하는 것
- 여러 가지 추상적인 개념의 관계를 보여주는 시각화된 다이어그램으로 구현
- 콘셉트 모델 작성은 모든 아이디어를 기록하는 것부터 시작.
- 상위 개념의 콘셉트는위쪽에, 하위 개념의 콘셉트는 아래쪽에 배치.
- 화살표를 이용해 콘셉트 간의 관계를표시하고 그 관계를 설명하는 단어나 문장을 명확하게 표기.
콘셉모델은 생각들을 구성하는 요소 중
“명사”에 해당하는 Entity 와 “동사”에 해당하는 Relation 으로 구성
콘셉트 모델의 주요 구성 요소:
- 명사(Entity): 콘셉트 모델에서 명사는 개념의 주체가 되는 요소를 나타낸다. 예를 들어, 사용자, 제품, 서비스 등이 명사에 해당할 수 있다.
- 동사(Relation): 각 명사 간의 관계를 나타내는 요소로, 동사는 개념들 간의 상호작용이나 연결을 설명한다. 예를 들어, 사용자가 제품을 사용한다, 또는 서비스가 문제를 해결한다와 같은 방식으로 명사와 명사를 연결한다.
<사용자>를 정의하고, <아이디어>를 구체화 하고, <여러 생각들>을 정리하고, <방향성>을 정의합니다.
콘셉트 모델 작성 과정:
- 구체적인 개념 정의: 먼저, 제품이나 서비스의 주요 요소들, 즉 사용자, 아이디어, 기능 등을 정의한다. 이는 명확한 구조를 제공하며, 각 개념이 어떤 역할을 하는지 설명할 수 있다.
- 추상적인 개념의 시각화: 콘셉트 모델은 추상적인 개념들 간의 관계를 시각적으로 표현한다. 이를 통해 다양한 개념들이 서로 어떻게 연결되고 상호작용하는지를 이해할 수 있다. 이 과정에서 화살표나 도형을 이용해 개념 간의 관계를 명확히 나타낸다.
- 아이디어 정리 및 구조화: 콘셉트 모델을 작성할 때, 모든 아이디어를 기록하고 이를 체계적으로 배치하는 것이 중요하다. 상위 개념은 위쪽에 배치하고, 하위 개념은 아래에 배치하여 위계 구조를 형성한다. 각 개념 사이의 관계는 화살표로 표시하고, 그 관계를 설명하는 단어를 추가한다.
- 사용 시나리오 표현: 모델 사용자가 제품이나 서비스를 어떻게 사용할지를 시각화된 다이어그램으로 표현한다. 이는 신규 제품을 기획하거나 기존 제품을 리뉴얼할 때 매우 유용하다.
flow와의 차이
콘셉트 모델(Concept Model)과 플로우(Flow)의 차이는 주로 목적과 표현 방식에서 나타난다. 두 개념 모두 UX 디자인 과정에서 중요한 역할을 하지만, 그 목적과 표현 방식은 다르다.
flow는 서비스나 제품의 메인 흐름과 그에 따른 단계들을 보여주는 것이 목적이다. 플로우는 사용자가 특정 목표를 달성하기 위해 서비스에서 어떤 경로를 따르는지, 각 단계에서 어떤 상호작용이 발생하는지를 시각적으로 나타낸다. 플로우는 주로 주요 경로와 그 경로와 관계된 흐름들을 시각화한다. 예를 들어, 사용자가 웹사이트에서 회원가입을 하는 과정을 보여주거나, 특정 기능을 사용할 때 어떤 단계를 거치는지를 표현한다.
반면, 콘셉트 모델은 플로우와 달리 추상적인 개념과 그 개념 간의 관계를 시각적으로 표현하는 데 목적이 있다. 제품이나 서비스에서 어떤 요소가 영향을 미치는지, 각 요소 간의 상호작용과 관계를 명확히 정의하는 것이 목표이다.
Flickr Concept Model :
Flickr의 콘셉트 모델은 이런 차이를 명확히 보여주는 대표적인 사례다.
‘A Flickr user takes Photos of a Subject’으로 상단에 이 서비스의 사용목적?을 알 수 있다. 그리고 Flickr/Photos/Subject의 각 객체가 다른 사용자 그룹이나 컨텐츠에 어떻게 녹여지고 사용될 수 있는지 그 아래에 텍스트/이미지/도형/선을 이용하여 풀고있고, 그 흐름들이 유기적으로 얽혀있다.
Flickr의 서비스 플로우는 사용자가 사진을 업로드하고, 친구들과 공유하며, 앨범을 만드는 흐름을 단계별로 보여준다. 반면, Flickr 콘셉트 모델은 이러한 사용자 흐름 속에서 사진, 사용자, 친구, 앨범 등의 요소들 간의 관계와 어떻게 그런 상호작용이 발생하는지를 시각적으로 나타낸다. 즉 콘셉트 모델은 그 흐름 속에서 어떤 목적으로 왜 그렇게 흘러가는지를 생각하는 것으로 흐름 속에서 영향을 미치는 요소와의 관계를 표현한 것이다.
예를 들면 다음은 Flickr.com의 서비스 개념을 컨셉맵으로 표현한 것입니다.
(출처, http://www.flickr.com/photos/bryce/58299511/)
Flickr의 콘셉트 모델은 사용자가 Flickr에서 사진을 업로드하고, 다른 사용자와 상호작용하며, 앨범을 만드는 과정이 어떻게 구성되고 연결되는지를 시각적으로 나타낸다. 이러한 시각적 표현은 추상적인 개념을 명확히 이해하도록 돕는다. 예를 들어, 사용자는 사진을 업로드하고, 이 사진에 태그를 달며, 다른 사용자와 사진을 공유할 수 있다. 이 과정에서 사진과 태그, 사용자 간의 관계가 시각적으로 표현된다.
- Entity: 사용자(User), 사진(Photo), 앨범(Album), 태그(Tag), 친구(Friend) 등.
- Relation: 사용자가 사진을 업로드한다, 사진에 태그를 추가한다, 앨범을 생성한다, 친구와 공유한다 등의 상호작용을 표현한다.
콘셉트 모델 작성 단계:
- 핵심 개념 정의: 모델에 포함될 **핵심 요소(명사, Entity)**를 식별하는 것이 첫 번째 단계이다. 이는 서비스나 제품의 주요 구성 요소를 포함한다. 예를 들어, 사용자가 어떤 서비스를 이용할 때 필요한 요소들이 무엇인지 정의한다.
- 예시: 사용자(User), 사진(Photo), 앨범(Album), 태그(Tag), 상품(Product), 주문(Order) 등.
- 관계(Relation) 설정: 각 개념 간의 관계(동사, Relation)를 정의한다. 관계는 각 요소가 서로 어떻게 상호작용하는지를 나타내며, 개념들이 어떤 방식으로 연결되는지 설명한다.
- 예시: 사용자가 사진을 업로드한다, 사진에 태그를 추가한다, 사용자가 상품을 주문한다 등.
- 아이디어 기록 및 구조화: 모델을 작성할 때 떠오르는 모든 아이디어를 기록하고, 이를 논리적으로 구조화한다. 상위 개념을 위에 두고, 하위 개념을 아래에 배치하여 위계 구조를 형성한다.
- 예를 들어, '사용자'가 '사진'을 업로드하는 행동이 상위에 있다면, '사진'에 '태그를 추가'하거나 '앨범에 저장'하는 하위 개념이 아래에 위치한다.
- 시각적 다이어그램 생성: 개념과 관계를 시각적으로 표현한다. 이는 보통 화살표나 선을 이용해 각 개념 간의 관계를 시각적으로 연결하여 표현한다. 개념들은 도형으로 나타내고, 관계를 설명하는 화살표로 연결한다.
- 예시: 사용자는 사진을 업로드하고, 사진은 앨범에 저장되며, 그 과정에서 태그가 추가되는 흐름을 화살표와 도형으로 연결하여 나타냄.
- 관계의 설명 및 구체화: 각 개념 간의 관계를 구체적으로 설명한다. 단어 또는 짧은 문장을 사용하여 관계가 어떤 의미를 가지는지 명확하게 설명한다.
- 예시: 사용자 → (업로드) → 사진 → (저장) → 앨범, 사용자 → (태그 추가) → 사진.
- 목적과 흐름 명확화: 이 모델이 무엇을 설명하고자 하는지 명확한 목적을 설정해야 한다. 왜 이런 흐름이 발생하는지, 사용자와 시스템 간의 상호작용을 통해 어떤 결과를 얻을 것인지를 설명한다. 이를 통해 전체 서비스의 방향성을 명확히 설정할 수 있다.
- 피드백을 통해 수정: 팀원이나 이해관계자들로부터 피드백을 받아 모델을 수정하고 개선한다. 이를 통해 모델이 더 명확하고 직관적으로 전달되도록 조정한다.
컨셉모델은 왜 만드는가?
개발자와의 커뮤니케이션이 이 Concept Model 하나로 한 방에 해결됩니다. 기획 초기에 Concept Model을 그려놓고 시작하는 것이 협업자간 커뮤니케이션에 엄청 큰 도움이 되는 이유가 여기에 있습니다. (설득이 시간이 엄청 줄어듭니다.)
3 브레인스토밍 -'함께 아이디어를 찾는 법'
**브레인스토밍(Brainstorming)**은 창의적인 아이디어를 발굴하기 위해 자유로운 사고와 의견 교환을 장려하는 방법으로, **알렉스 오스본(Alex Osborn)**이 개발한 기법이다. 이 방법은 **관념화(Ideation)**를 목적으로 하는 모든 미팅에서 많이 사용되며, 제한 없이 아이디어를 발상하는 과정이 핵심이다. 특히, 디자인 씽킹 프로세스에서 HMW(How Might We)
질문이 많이 사용되는 브레인스토밍은 창의적 문제 해결에 매우 유용하다.
• 대표적인 아이디어 발상법으로, 관념화를 목적으로 하는 모든 미팅.
• HMW(How Might We)는 브레인스토밍에서 가장 많이 사용되는 디자인 씽킹 프로세스 중 하나.
브레인스토밍(Brainstorming)은 창의적인 아이디어를 찾기 위한 학습/회의 방법입니다.
알렉스 오스본Alex Osborn이 개발한 기법으로 회오리바람(Storming)을 일으킨다는 의미가 있어 참가자(stormer)들은 사고의 제한없이 자유롭게 아이디어를 내게 됩니다. 물론 혼자서도 해볼 수 있습니다.
알렉스 오스본의 네 가지 브레인스토밍 원칙:
- 아이디어는 많으면 많을수록 좋다: 브레인스토밍의 목표는 가능한 한 많은 아이디어를 발굴하는 것이다. 아이디어의 양을 우선으로 하여, 이후에 좋은 아이디어를 선택하고 발전시킬 수 있다.
- 각 아이디어에 대해 어떤 비판도 하지 않는다: 브레인스토밍 과정에서 비판이나 평가는 금지된다. 아이디어를 제안하는 단계에서는 비판 없이 자유롭게 아이디어를 낼 수 있어야 창의성이 극대화될 수 있다.
- 별난 아이디어도 환영한다: 독창적이고 기발한 아이디어일수록 환영된다. 처음에는 말도 안 되는 것처럼 보이더라도 나중에 새로운 혁신적인 해결책으로 이어질 가능성이 있다.
- 의견의 조합과 개선을 장려한다:제시된 아이디어를 단순히 평가하는 데 그치지 않고, 의견을 결합하고 발전시키는 것을 장려한다. 여러 사람의 아이디어가 합쳐져 더 나은 해결책을 만들어낼 수 있다.
이 네 가지 원칙을 통해 브레인스토밍은 참여자들이 자유롭게 아이디어를 제안하고, 창의적인 문제 해결 방법을 도출하는 데 도움이 되는 효과적인 방법으로 자리잡았다.
| 장점 | 단점 |
| - 주제에 제한이 없고 실행하기 쉽다 - 질보다 양에 초점 - 비교적 자유롭게 의견 제안 |
- 동기 없는 참가자는 시간을 낭비하는 등 효율성이 떨어질 수 있음 - 집단수준에서 의사결정이 이루어지기 쉬움 - 다른 이들의 부정적 평가가 두려워 스스로 의견을 왜곡할 수 있음 - 권위적이거나 강요와 압력을 행사하는 사람이 있다면그가 원하는 방식으로 결론이 도출될 수도 있음 |
앞에서 페르소나 등의 모델링을 통해 사용자가 가진 이슈를 파악 했다면 그것을 해결할 수 있도록 더 나은 가치와 경험을 제공하기 위해 특징 Feature에 대한 아이디어를 발굴하고 설계하고 디자인하는 과정을 거치게 된다.
그중에서도 HMWHow Might We는 브레인스토밍에서 가장 많이 사용되는 디자인 씽킹 프로세스 중 하나이다.
HMW 질문은 "어떻게 하면 우리가 ~할 수 있을까?"라는 형태로, 사용자의 불편함이나 요구를 해결하기 위한 구체적인 아이디어를 이끌어낸다. 이를 통해 추상적인 문제를 실행 가능한 계획으로 구체화할 수 있다. 예를 들어, "어떻게 하면 사용자가 상품을 더 쉽게 찾을 수 있도록 도와줄 수 있을까?"라는 질문은, 사용자의 탐색 과정을 단순화하거나 개선할 수 있는 기능을 설계하는 데 중요한 단서가 될 수 있다.
앞서 언급했듯이 중요한 점은 올바른 질문을 던지는 것이 해결책의 질을 결정한다는 것이다. 문제를 명확하게 정의하면 더 나은 아이디어가 나올 수 있고, 그 결과 사용자에게 더 나은 가치를 제공하는 기능을 설계할 수 있다. HMW 질문은 이러한 과정에서 문제를 작은 부분으로 나누고, 구체적인 해결책을 찾는 데 매우 유용한 도구가 된다.
이 표는 다양한 브레인스토밍 기법을 비교하여 각 기법의 특징과 활용 상황을 보여준다.
| 방법 | 방식 | 활용 |
| 브레인스토밍 | 이야기하면서 아이디어 발산 | 주제에 대한 전문 지식이 있고 자유로운 토론이 가능할 때 활용 |
| 브레인라이팅 | 글로 적으면서 아이디어 발산 | 혼자서 조용히 생각을 정리한 후, 참여자들과 공유할 때 활용 |
| 브레인드로잉 | 그림으로 그리면서 아이디어 발산 | 집중하면서 자유롭게 그림 그리는 것에 익숙한 참여자들일 때 활용 |
| 보디브레인스토밍 | 몸으로 연기하면서 아이디어 발산 | 자유롭게 몸으로 이야기할 수 있는 환경이 갖춰진 경우 활용 |
그렇다면 어떤 상황에서 어느 방법을 사용하면 좋을까요?
아이디어 확산을 촉진하는 방법에는 관련 문제에 대해 “말”하거나 “글”로 쓰는 방법, “그림으로 그리거나 “몸”으로 이야기하는 방법이 있습니다.
그중 말로 이야기하는 것을 브레인스토밍(Brainstorming)이라 부르는데, 이는 참여자들과 함께 아이디어를 이야기하는 방식입니다. 참여자들이 서로 친밀하고, 주제에 대해 전문 지식을 갖춘 상태라면 더욱 효과적이죠.
- 브레인라이팅(Brain Writing)은 주제에 대해서 조용히 고민할 시간을 갖고, 생각을 정리해서 표현해야 할 상황에 효과적입니다. 정리된 아이디어는 혼자만 갖고 있는 것이 아니라 참여자들이 수건돌리기 하듯 3X4 테이블 시트를 돌려 아이디어를 하나씩 적어가며 공유하는 과정에서 풍성해집니다. 조용한 가운데 집중하면서 효과적으로 아이디어를 확산시킬 수 있는 방법이죠.
- 이외에도 브레인드로잉(Brain Drawing)은 머릿속에 떠오르는 아이디어를 빠르게 그려내는 방식으로, 마치 낙서처럼 보일 수도 있습니다. 하지만 아이디어 전달만 잘 된다면 그림 실력은 상관없겠죠. 그림은 동심으로 돌아가 마음을 편하게 해주고, 시각적 자극이 되어 더욱 창의적인 아이디어를 만들어냅니다.
- 마지막으로 보디브레인스토밍(Body Brainstorming)이라는 방법은 상황 설정이 가능한 상태에서 머릿속에 떠오르는 아이디어를 몸짓 또는 행동으로 표현하는 것입니다. 우스운 모습이 연출되지만 몸을 움직이면서 자극을 통해 상황에 더 적합한 아이디어와 미처 생각하지 못했던 창의적인 아이디어를 자연스럽게 떠올리는 데 효과적입니다.
유념사항
HMW를 진행할 때는 추상적이거나 너무 작은 단위의 문제라서 해결책을 제시하기 곤란하거나 아이디어를 제공할 필요가 없는 부분은 배제하는 것이 좋다.
진행자의 자세 :
브레인스토밍에는 진행자가 반드시 참석하며 진행자는 아이디어를 제안하지 않는 것이 바람직하다.
- 진행자(리더)는 어떤 의견이든 수렴하는 분위기를 만들며 자신의 의견으로 판단하거나 특정인의 의견으로 치우치지 않도록 주의해야 합니다.
- 발언자가 많은 경우에는 순서대로 발언의 기회를 줄 수 있고 특정인의 발언이 독점된다면 적절한 선에서 정리를 해줄 필요도 있습니다.
- 의견이 활발하게 나와 서기(기록자)가 의견을 받아 적는데 어려움이 있다면 진행자는 회의의 속도를 조정하여 참여자들의 아이디어를 놓치지 않도록 해야 합니다. 이러한 분위기를 위해서는 참가자들 모두의 노력이 필요하겠지만 특히 리더(진행자)의 배려와 센스, 촉진과 조정의 능력이 중요하겠습니다.
- 10~15분 진행한 후에는 잠시 휴식을 취하는 것이 좋고 이 과정을 세 번 정도 수행하면서 도출된 아이디어를 분류하고 그럴듯한 아이디어로 정제하는 과정을 거친다.
즉, 현 상태As-is의 문제점을 파악하고 개선 후To-be에 사용자의 니즈를 충족시킬 수 있는 아이디어를 발견하는 것을 목적으로 특징 리스트Feature List를 작성하면 좋다.
특징 리스트 작성 예시:
- As-is: 사용자가 결제 과정에서 많은 단계를 거쳐야 하는 불편함이 있음.
- To-be: 결제 단계를 간소화하여, 한 번의 클릭으로 결제가 완료되는 기능을 추가.
- Feature List:
- 간편 결제 기능
- 결제 정보 자동 저장 기능
- 결제 상태 실시간 알림 기능
이러한 방식으로 현 상태와 개선 후 상태를 비교 분석하여, 사용자 경험을 개선할 수 있는 구체적인 기능 리스트를 작성하면 효과적이다.
4. 사용자 스토리 User Story
User Story는 사용자의 관점에서 작성된 간단한 설명으로, 특정 기능이 사용자에게 제공하는 가치를 설명하는 도구이다. 주로 애자일 개발에서 사용되며, 개발팀이 이해하기 쉽도록 기능 요구사항을 짧고 간결하게 표현하는 방식이다. User Story는 개발팀과 이해관계자들 간의 대화를 이끌어내는 도구로도 활용되며, 사용자 경험과 요구사항을 명확히 전달하는 역할을 한다.
사용자 스토리의 필요성
사용자 스토리는 사용자 관점에서 기능을 설명하여 사용자 중심의 개발을 촉진하고, 팀 내에서의 원활한 커뮤니케이션과 우선순위 설정을 돕는다. 또한, 유연하고 변화에 쉽게 적응할 수 있는 개발 환경을 제공함으로써, 효과적인 애자일 개발 프로세스의 중요한 요소가 된다.
**스윙 프로젝트(타이어 그네 프로젝트)**는 프로젝트 관리와 의사소통의 중요성을 풍자적으로 표현한 그림이다. 이 그림에서는 고객, 개발자, 디자이너, 클라이언트가 동일한 프로젝트에 대해 서로 다른 이해를 갖고 있는 상황을 보여준다.
- How the customer explained it (고객이 설명한 것): 고객이 단순하게 그네를 설명함.
- How the Project Leader understood it (프로젝트 리더가 이해한 것): 리더는 다르게 해석함.
- How the Analyst designed it (애널리스트가 설계한 것): 과도하게 복잡하게 설계함.
- How the Programmer wrote it (프로그래머가 구현한 것): 설계와 달리 실제로 개발된 것은 간단함.
- How the Business Consultant described it (비즈니스 컨설턴트가 설명한 것): 비즈니스 측에서는 과장된 방식으로 설명함.
- How the project was documented (프로젝트가 문서화된 방식): 프로젝트 문서는 핵심을 빠뜨리고 매우 간단함.
- What operations installed (운영에서 설치한 것): 운영 팀은 제대로 설치하지 못함.
- How the customer was billed (고객이 청구받은 것): 고객은 과도하게 비용을 청구받음.
- How it was supported (지원 방식): 지원도 제대로 이루어지지 않음.
- What the customer really needed (고객이 실제로 필요로 했던 것): 고객이 원했던 건 단순한 타이어 그네였음.
이 그림은 프로젝트가 진행되는 과정에서 고객의 요구와 최종 결과물이 어떻게 다르게 나올 수 있는지, 그리고 각 단계에서 발생하는 의사소통의 문제점을 보여줍니다. 이를 통해 사용자 스토리와 명확한 의사소통의 중요성을 강조하고 있습니다.
그러므로 관계자가 모두 같은 방향을 바라볼 수 있도록 사용자 스토리를 작성하고 공유해야 한다. 사용자 스토리는 계획이나 약속이라기보다는 개발팀과 사용자의 대화를 이끌어내는 도구다.
User Story 구성:
- 사용 주체: 특정 역할을 가진 사용자가 누구인지 명시합니다. 예: "As a user, I want to..."
- 기능: 사용자가 원하는 동작이나 기능을 간결하게 설명합니다. 예: "I want to search for products easily."
- 목적/가치: 그 기능을 통해 사용자가 얻고자 하는 목표나 이점을 설명합니다. 예: "So that I can save time."
이 구조를 통해 사용자 스토리는 간단하지만 매우 중요한 기능을 정의하는 데 유용한 도구로 작동하며, 개발팀과 이해관계자 간의 소통을 원활하게 하는 역할을 합니다.
작성법 :
- 짧고 간결한 설명: 핵심 내용을 짧고 명확하게 설명하며, 기술적 용어보다는 비즈니스 언어로 작성하여 누구나 쉽게 이해할 수 있도록 합니다.
- 테스트 가능성: 기능이 어떻게 테스트될 수 있는지도 서술할 수 있습니다.
사용자 스토리 예시:
- "As an online shopper, I want to be able to search for products by category so that I can find what I’m looking for quickly."
예제 : 취미 정보를 제공받고 활동하는 사용자 스토리를 표로 구성하였습니다. 각 항목은 장면, 시나리오, 니즈, 사용자 행동, 기능을 포함하며, 여러 내용이 포함된 열로 정리되었습니다.
| 구분 | 내용1 | 내용2 | 내용3 |
| 장면 | 취미 정보와 후기 정보로 활동을 결정하고, 신중하게 참가를 결정 | 후기를 기록하고 남기며 다른 사람들과 공유 | 다른 사람의 피드백과 결과물 확인 |
| 시나리오 | 거쳐간 정보와 후기 정보를 통해 자신의 취미를 확신하고 활동을 선택 | 후기 작성을 통해 다음 사람들에게도 도움이 될 수 있도록 작성 | 수업 이후에도 계속해서 활동을 이어나감 |
| 니즈 | 취미 활동 장소와 날짜를 다시 알림으로 알려주면 좋겠다고 생각 | 활동 후 후기를 기록하고 공유하고 싶은 욕구 | 활동 결과물과 피드백을 공유하고 확인할 수 있는 기능 필요 |
| 사용자 행동 | 취미 활동에 참여한다 | 후기를 작성한다 | 다른 사람의 작품을 보고 자극을 받음 |
| 기능 | 취미 활동 장소와 날짜에 대한 알림 기능 | 후기 작성 기능 | 관심 있는 활동을 검색하고 좋아요/댓글 기능 제공 |
예제 : 운동 기록 기반 사용자 시나리오를 바탕으로 한 기능 설계 예시
| 구분 | 내용 |
| 장면 | 사용자가 운동 기록을 확인하고 자신의 운동 목표를 달성하기 위한 계획을 세움 |
| 시나리오 | 사용자는 매일의 운동 기록을 차트로 확인하고, 목표 달성 여부를 판단함 |
| 니즈 | 운동 목표 달성률과 진도를 쉽게 확인할 수 있는 기능이 필요함 |
| 사용자 행동 | 운동 기록을 매일 확인하고 목표에 도달했는지 체크함 |
| 기능 | 운동 기록 대시보드, 목표 설정 및 달성률 시각화 기능 |
5. 유스 케이스(Use Case)
- 유스 케이스Use Case란 시스템의 동작을 사용자 입장에서 표현한 시나리오이다.
- 시스템에 관련된 요구 사항을 알아내는 과정으로, 시스템을 분석하는 사람과 사용자가 함께 시스템의 사용 방법을 결정하는데 도움이 되는 도구이다.
유스 케이스를 작성할 때 주의할 점
- 간결성: 사용자가 이해하기 쉽게 간단하게 작성해야 한다.
- 주요 기능에 집중: 모든 기능이 정상적으로 작동하는 경우를 중심으로 작성하고, 예외적인 상황은 나중에 정의한다.
- 단편적인 표현: 시나리오나 스토리와는 다르게 하나의 기능에 집중하여 작성한다.
- 빈번한 상황에 집중: 사용자에게 자주 발생하는 상황을 우선적으로 작성한다.
사용자가 이해하기 쉽도록 간단하게 작성해야 한다는 것이다. 모든 것이 완벽하게 돌아가는 상황에 초점을 맞추고 예외 적인 케이스는 나중에 정의한다. 빈번하게 발생하는 일에 더 집중하며 시나리오나 스토리와는 다르게 하나의 기능을 표현하기 때문에 단편적으로 사용한다.
유스 케이스 예시 - 커피숍에서 커피를 주문하는 경우:
예를 들면 커피숍에서 커피를 마시는 장면을 유스 케이스로 나눠보면 다음과 같다.
- 사용자 목표: 사용자는 커피숍에서 커피를 주문하고 결제한다.
- 유스 케이스 단계:
- 사용자: 커피숍에 도착하여 메뉴를 확인한다.
- 시스템: 사용자가 선택한 메뉴를 주문받는다.
- 사용자: 결제 방법을 선택하고 결제한다.
- 시스템: 결제가 완료되고 주문이 접수된다.
- 사용자: 커피를 기다리다가 받아서 가져간다.
유스 케이스 작성 단계:
- 유스 케이스 목록 정의: 시스템과 관련된 모든 기능을 나열한다.
- 통합과 정리: 나열된 기능을 통합하고 정리하여 각 유스 케이스가 독립적으로 기능하도록 작성한다.
- 세부 단계 정의: 각 유스 케이스의 세부 단계와 흐름을 정의한다.
- 예외 처리: 정상적인 경우 외에 예외적인 상황을 나중에 추가로 정의한다.
유스 케이스 작성에 관해서 완벽하게 정해진 규칙은 없지만 관련 항목에 대한 모든 목록을 정의하고 차례대로 통합과 정리를 하는 과정을 거치며 대체적으로 다음과 같은 단계를 거친다.
① 시스템에 대한 사용자의 요구 사항을 찾는다.
② 시스템의 유스 케이스와 관계된 모든 행위자Actor를 찾는다.
③ 행위자가 요구하는 모든 유스 케이스를 찾는다.
④ 공통된 유스 케이스에 대한 서비스를 정제한다.
⑤ 유스 케이스를 목록으로 만들고, 각 유스 케이스의 주요 요소를 식별한다.
- 유스 케이스의 이름과 간략한 설명을 작성한다.
- 주요 플로우(모든 일이 순조롭게 진행되는 케이스)와 대체 플로우(일이 순조롭지 못할 때 대안 또 는 예외적인 케이스)를 작성한다.
⑥ 유스 케이스 문서를 작성한다.
유스 케이스 다이어그램Use Case Diagram을 작성할 때는 다음과 같은 사항을 참고하면 좋다.
· 시스템 영역 표시는 잘 사용하지 않으며, 불필요한 경우가 많다.
· 행위자와 유스 케이스의 관계를 연관Association이라고 한다.
· 행위자와 유스 케이스 사이의 연관에는 화살표 없는 실선을 사용해 단순하게 그린다.
· 화살표는 의미가 불분명한 경우가 많으므로 사용하지 않는 편이 낫다.
· 포함Include 관계는 하나의 유스 케이스가 다른 유스 케이스를 항상 포함한다는 의미이다.
· 확장Extend 관계는 하나의 유스 케이스로부터 다른 유스 케이스로 기능이 확장될 수 있다는 의미이다.
· 확장 관계의 화살표 방향은 확장 대상이 되는 유스 케이스로부터 확장점을 가진 유스 케이스로 향한다.
· 확장 관계는 상속이 아니다.
· 기능의 상속은 일반화Generalization라고 하며, 머리가 삼각형인 실선으로 표시한다.
[그림 2-29]에서 행위자는 인터넷뱅킹 사용자이고, ‘즉시 이체’라는 유스 케이스와 연관 관계가 있다.
즉시 이체를 수행하면 출금 계좌의 잔고를 확인하고 이체 한도를 조회하는 기능을 먼저 수행하게 되므로 ‘잔고 조회’ 유스 케이스와 ‘한도 조회’ 유스 케이스는 ‘즉시 이체’ 유스 케이스의 포함 관계 대상이 된다. ‘즉시 이체’ 유스 케이스로부터 ‘추가 이체’ 유스 케이스를 실행할 수도 있으 므로, ‘즉시 이체’와 ‘추가 이체’는 확장 관계가 된다.
‘자동 이체’는 ‘즉시 이체’의 구체적인 유스 케이스 개념이므로 일반화 및 상속 관계로 표현할 수 있다.
위 이미지 예시는 **도서관 관리 시스템(Library Management System)**의 유스 케이스 다이어그램을 보여줍니다. 이 다이어그램은 두 그룹의 사용자 간의 주요 상호작용을 시각적으로 나타냅니다: **사서(Librarian)**와 대출자(Borrower).
유스 케이스 다이어그램 구성 요소:
- Librarian(사서):
- 로그인(Log in): 사서는 시스템에 로그인하여 다양한 기능을 이용할 수 있다.
- 도서 관리(Manage books): 사서는 도서 추가(Add book), 도서 업데이트(Update book), 도서 삭제(Remove books), 도서 검색(Search books) 등의 작업을 수행한다.
- Borrower(대출자):
- 도서 대출(Borrow book): 대출자는 도서를 대출할 수 있다.
- 도서 반납(Return book): 대출자는 대출한 도서를 반납할 수 있다.
- 도서 정보 보기(View book details): 대출자는 도서의 세부 정보를 열람할 수 있다.
포함 관계 (Include)
- 다이어그램에서 각 기능 사이에 "include"라는 관계가 사용되어, 한 유스 케이스가 다른 유스 케이스를 반드시 포함해야 함을 나타낸다. 예를 들어, "도서 관리(Manage books)"는 "도서 추가(Add book)" 등의 세부 작업을 포함한다.
이와 같은 유스 케이스 다이어그램은 시스템의 사용자 역할과 그들이 시스템에서 수행할 수 있는 주요 작업을 명확하게 보여주어, 시스템 설계와 개발 단계에서 중요한 자료로 활용된다.
Use case vs User story
둘다 사용자가 보이는 패턴을 규정한다는 측면에서 유사한 면이 있으나, 유스케이스가 서비스이용시 예상되는 행위들을 단순 나열이라면, 사용자 시나리오는 특정한 맥락에서 동기 고충, 니즈, 태도 등의 경험요소들을 이야기 형태로 서술
Use Case 예시: |
User Story (사용자 스토리) |
|
커피 주문 사용자 스토리:
|
- Total
- Today
- Yesterday