TIL 260223 AI 다루기, JTBD 외

프롬프트 엔지니어링

AI에게 명령할 때 디테일하게 요구하기 위한 요소를 체화하는 게 필요할 거 같다고 생각했다.

다만, 너무 상세히 작성하다 보면 힘들거니와 효율이 그만큼 떨어지기에

어떤 요소를 꼭 넣고 어떻게 명령해야 할지 중요해 보였다.

프롬프트 엔지니어링을 배운 것과 별개로 어떤 포인트를 짚어줘야 나랑 꼭 맞게 나와줄지 세세하게 말해야 하는 것이 말이다.

 

타 수강생분들은 이런 식으로 프롬프트를 작성하셨는데 인상 깊었다.

1. 상황, 텍스트, 포인트를 핵심으로 짚음

2. 먼저 대화로 페르소나를 간단히 만들고, scene - visual - action&UI - story(caption)으로 구성

 

따라, 스토리 보드를 구상할 때 AI에게 퍼소나를 먼저 맡겨서 이미지 프롬프트 생성까지 맡기는 것이 가장 편리하겠다고 생각했다.

---

Jobs To Be Done (task)

페르소나는 실제 데이터로 행동을 예측해서 만들어짐. '누구'에 주목해 행동적 특성을 보여주지만 행동의 맥락을 설명해주지 않기 때문에 JTBD가 나왔다. JTBD는 핵심 요소인 고객-과업-니즈로 구성됨.

JTBD 없이 프로젝트를 진행하면 뾰족한 인사이트가 없어 기능 디테일은 많지만 차별화는 없는 앱이 될 수 있다

페르소나는 인구통계학적 특성을 기반으로 특정 인물이 있지만, JTBD는 목적에 집중하기 때문에 서로 다른 인구통계학적 특성을 가진 인물들이 같은 목적을 가진 채로 처한 상황과 과업을 분석하는 데에 초점을 두고 있다.

*JTBD canvas 참고

 

JTBD관점에서 표면적 니즈(사용자가 생각하는 pain point)와 근본적 욕구 job를 구분해서 설명할 줄 알아야 함.

밀크셰이크가 어떤 필요성에 의해서 구입되는가를 조사했을 때,

판매의 상당 부분이 이른 아침, 테이크아웃

따라, 사람들의 job은

1. 긴 출근길을 덜 지루하게

2. 점심시간까지 배고프지 않게

3. 한 손으로 간편하게

4. 차 안을 더럽히지 않고 깔끔하게

위의 니즈를 모두 만족하는 밀크셰이크가 바나나, 도넛, 베이글, 스무디의 대체템이었다

제품 개선 : 더 진하게, 오래 지속되도록, 과일 조각을 넣어 먹는 재미를 더함, 아침시간대에 회전율 높이기 위한 자판기 자동화

what if , 제품특성이나 인구통계학적 특성만 쳐다보았다면 이런 인사이트를 발견할 수 없었을 것.

 

표면적 니즈 : 많은 사람들이 아침에 밀크셰이크를 사 먹는 니즈는 간단히 아침 때우기일 것이다? 디저트가 먹고 싶어서 일 것이다?

JTBD : 출근시간이라는 상황 속에서 편리함, 점심시간까지 배고프지 않게, 긴 출근 시간을 덜 지루하게, 하루를 활기차게 보내기 위한 

 

job statement 원하는 결과와 맥락을 명확히 문장으로 기술 상황 - 동기 - 목표 3요소 구성

'바쁜 출근 시간에 건강한 아침 식사를 준비하여 하루를 활기차게 시작하고 싶다.'

위 job statement 서술이 완벽한 이유 : 솔루션이 중립적이어서 특정 제품 제한 x 개인의 요구와 욕구를 강조 아침 식사를 준비하는 행위만 명시한 것이 아니라 그 결과까지 명확히, 사용자의 맥락을 구체적으로 담고 있음.

 

사용자 리서치 결과를 인사이트를 실제 기능(프로덕트)으로 만드는 과정

기능 정의 목적 : 사용자 요구를 설계에 반영 / 팀 내 명확한 커뮤 / 프로젝트 방향성 설정

기능도출까지가 논리적이지 못하면 제품이 불분명해지고 팀원 간 불화, 리소스 낭비 등의 단점 초래

인사이트를 정보로 남기지 않고 기능 개선까지 이어가는 것이 제품 개선의 핵심

기능 명세서로 블루프린트를 확실하게 규범

step 1) 리서치 인사이트 발견

step 2) 근본 원인 분석

step 3) 도출된 기능

step 4) 우선순위 결정

step 5) 단계별 구현 계획

step 6) 최종 기능 명세서 작성

 

인사이트 정리 : 리서치 데이터를 단순 관찰에서 구체적인 행동 시나리오로 전환

근본 원인 분석 : 행동 관찰과 사용자 피드백에서 드러난 패턴을 분석하여 근본적인 문제 파악 (5 why)

기능 브레인스토밍 : 각 인사이트별로 해결 가능한 기능을 폭넓게 도출(기술적 제약/비용 고려 x)

우선순위 정하기 : 우선순위 프레임워크를 사용

• Effort/impact matrix
• RICE framework 정량적 프레임워크 Reach(도달자 수) * Impact(영향력 순위) * Confidence(확신 정도) + Effort(노력)
• MoSCoW 우선순위
• ROI (Return on Investment)

---

개념 비교

needs 근본적인 목적으로서 수단을 언급하지 않고 표현

wants 니즈를 실현할 수단을 언급

pain point 사람이 겪는 불편함

 

job statement 사용자가 특정 상황에서 얻고자 하는 최종 결과와 감정 상태

템플릿 : [상황]일 때, [동기/행동]해서, [기대 결과]를 얻고 싶다.

용도 : 서비스의 방향성 과 가치 결정

 

problem statement 기획자가 문제를 정의하는 문장 (해결 방안 x, 해결 방향까지 포함)

용도 : 구체적인 기능과 해결책 도출

템플릿 : [사용자]는 [목표]를 하고 싶어 하지만, [페인 포인트] 때문에 어려움을 겪고 있다. 따라서 우리는 [해결 방향]을 제공해야 한다.

 

JobsToBeDone 완료해야 하는 과업

템플릿 : 표준 job story 템플릿 - [상황] 일 때, [동기] 해서, [기대하는 결과]를 얻고 싶다. (when _, I want to _, So I can _)

 

• [상황] (Situation): 사용자가 처한 맥락 (언제, 어디서, 누구와)
• [동기] (Motivation): 해결하고 싶은 구체적인 욕구 (무엇을 하고 싶은가)
• [기대하는 결과] (Expected Outcome): 그 일을 마쳤을 때 느끼는 가치나 변화

 

---

이렇게 공부해도 JTBD가 머릿속에 확실히 이해되지 않았다. 그래서 용도나 이유를 제미나이에게 물어서 답변하기를,

 

JTBD(Jobs To Be Done)를 처음 접하면 "그냥 니즈(Needs)랑 똑같은 거 아냐? 왜 굳이 '고용한다'는 표현까지 써가며 복잡하게 정의하지?"라는 의문이 드는 게 당연합니다.

결론부터 말씀드리면, JTBD의 핵심 의의는 **'제품의 경쟁 범위를 무한대로 확장해서 진짜 경쟁자를 찾게 해 준다'**는 데 있습니다.

 

다양한 니즈는 특정한 상황을 만들고, 그 상황을 해결하고자 정의하는 이것이 바로 jtbd? 반대로 JTBD를 쪼개면 다양한 니즈로 작게 쪼개진다는 것

1. 경쟁의 범위를 '카테고리'가 아닌 '상황'으로 넓혀줍니다

기존 방식대로 정의하면 "밀크셰이크의 경쟁자는 다른 브랜드의 밀크셰이크나 아이스크림"입니다. 하지만 JTBD로 정의하면 완전히 달라집니다.

• Job: "아침 출근길, 운전하며 지루하지 않게 허기를 달래줄 무언가가 필요해."
• 경쟁자들: 바나나, 도넛, 베이글, 그리고 밀크셰이크.
• 의의: 고객은 밀크셰이크가 맛있어서가 아니라, 한 손으로 운전하며 오래 먹기 좋다는 '상황' 때문에 선택한 것입니다. 이를 알면 초콜릿 칩을 더 넣는 대신, '더 걸쭉하게 만들어 더 오래 빨아먹게 만드는' 혁신이 가능해집니다.

2. 인구통계학(Persona)의 한계를 극복합니다

"30대 서울 거주 남성"이라는 페르소나는 그가 왜 제품을 샀는지 설명해주지 못합니다. 30대 남성도 친구와 있을 때와 혼자 있을 때 제품을 사는 이유가 다르기 때문이죠.

• 의의: 사람의 속성이 아니라 **'그 사람이 처한 상황'**에 집중합니다. "나이와 성별이 같아도 상황(Job)이 다르면 다른 제품을 고용한다"는 관점은 훨씬 더 정확한 마케팅과 기획을 가능하게 합니다.

3. 기능(Feature)이 아닌 '진보(Progress)'에 집중하게 합니다

사용자는 드릴(Wants)을 원하는 게 아니라, 벽에 난 구멍(Needs)을 원하며, 궁극적으로는 **가족사진을 걸어둔 안락한 거실(JTBD)**을 원합니다.

• 의의: "우리는 드릴 만드는 회사야"라고 정의하면 레이저 측정기나 강력 접착제가 나왔을 때 망합니다. 하지만 "우리는 안락한 거실을 만드는 걸 도와주는 회사야"라고 JTBD로 정의하면, 기술이 변해도 고객의 목적을 달성해 줄 새로운 수단을 계속해서 기획할 수 있습니다.

💡 왜 '고용(Hire)'이라는 단어를 쓸까요?

우리가 직원을 뽑을 때 특정 '업무'를 맡기기 위해 고용하듯, 고객도 자신의 삶에서 해결되지 않는 문제를 처리하기 위해 가장 적합한 제품을 잠깐 '고용'한다고 보는 것입니다. 만약 그 제품이 일을 제대로 못 하면 바로 '해고'하고 다른 제품을 찾게 되죠.

요약하자면 JTBD를 쓰는 이유는:

1. 진짜 경쟁자가 누구인지 알기 위해 (콜라의 경쟁자는 물이 아니라 '잠'일 수 있다)
2. 어떤 상황에서 우리 제품을 찾는지 알기 위해
3. 제품의 기능 개선을 넘어 사용자의 삶을 어떻게 변화시킬지 설계하기 위해

---

IA와 플로우차트

IA는 공간 구조 설계 (depth)

flowchart는 목적에 따른 시간의 흐름 설계

 

AI 실습 프롬프트

1차 : 나는 디저트 추천 서비스를 만들 거야 주요 기능은 디저트 검색, 추천 목록, 사용자 리뷰가 있어 서비스의 기본 설정을 구성하고 IA 설계와 플로우차트 작성해 줘

2차 : 정보를 그룹화하여 주요 카테고리를 생성하고, 계층 구조를 기반으로 세부 구조를 설계하고 사용자의 행동과 시스템 반응을 단계별로 시각화하여 플로우차트를 작성해 줘

 

---

와이어프레임의 정의와 필요성 ★★★★★

화면설계의 기본 도구로서 디지털제품의 레이아웃과 디자인 요소를 쉽게 시각화한 것

아이디어를 빠르게 시각화, 팀원들과 커뮤니케이션, 작업 전 팀원들과 중요한 ux 결정사항 공유, 기능과 구조를 명확히 이해

제품 화면의 기초 뼈대를 제시하여 팀원 이해를 도모 색감 없이 레이아웃과 정보배치만 보여주기 때문에 개발자 디자이너 모두 같은 출발선에서 의견 나눌 수 있음 이를 통해 초기단계부터 구조적 문제를 빠르게 수정할 수 있고 불필요한 작업 비용을 줄임으로써 효율적인 소통에 큰 기여

 

Claude AI 활용 와이어프레임/화면 설계

기능 정의 후 구현 시, 맥락 혹은 역할 제시 + 기능 명세서  제공 후 제작 요청

기존 와이어프레임 솔루션 도출 시, 정의한 문제 + 목적 + 핵심명령 구조로 질문

기존 와이어프레임 솔루션 구현 시, 솔루션 + 솔루션 UI

---

카피라이팅 vs UX라이팅

카피라이팅과 UX라이팅의 가장 큰 차이는 스토리텔링 목적(구매욕 자극 + 감성소구 브랜딩)이냐 정보전달 목적(논리적인 맥락 이해 + 프로덕트 사용성을 위한 task 안내 도우미 )이냐이다

 

UX라이팅의 핵심 원칙! 

명확 & 간결

보이스 & 톤 

감정적인 연결 형성

긍정적인 강화 사용

사용자의 맥락과 니즈 이해

전환율을 높이는 라이팅/FOMO

 

토스의 8가지 Don't & Do

1. predictable hint : 다음 화면을 예상할 수 있는 힌트가 있는가?

2. weed cutting : 의미 없는 단어를 모두 제거했는가?

3. remove empty sentences : 의미 없는 문장을 모두 제거했는가?

4. focus on key message : 정말 중요한 메시지만 전달하고 있는가?

5. easy to speak : 이해하기 어려운 용어나 표현을 사용하지 않았는가?

6. suggest over force : 특정 행동을 강요하거나 공포감을 주고 있지 않은가?

7. universal words : 모두가 이해할 수 있고 모두에게 무해한가?

8. find hidden emotion : 단순히 정보를 전달하는 것을 넘어 사용자의 감정에 공감했는가?

 

코드잇의 UX라이팅도 되게 인상 깊었던 게 선을 잘 타는 것 같았다. 조급함을 불러일으킨 다음 준비된 내용으로 안심시켜서 더 큰 신뢰를 얻어내는 랜딩 페이지가 되게 인상 깊었다.

---

도허티 임계(doherty threshold) 0.4초에 대처하는 다양한 방법이 있음(프로그레스바, 스켈레톤, 블럭)

신뢰가 필요한 프로세스의 경우, 너무 빠르게 진행되어도 신뢰성을 잃을 수 있음.

속도가 중요한 경우에는 0.4초 이상 걸릴 경우 대기 화면에 로딩화면/프로그레스 바 추가로 시선을 분산시키는 방법이 있음.

---

 

닐슨의 10가지 휴리스틱 사용성 평가 기준

1. 시스템 상태 시각화 - 사용자가 현재 시스템 상태를 항상 알 수 있도록 해야 함.

2. 현실 세계 부합 - 시스템 언어와 사용자의 언어가 일치하도록 설계해야 함.

3. 통제권, 제어 자유 - 사용자가 현재 시스템 상태를 항상 알 수 있도록 해야 함.

4. 일관, 표준성 - 플랫폼 간에 일관성을 유지하고 표준을 따름.

5. 오류 미연 방지 - 사용자 오류를 방지할 수 있는 설계를 해야 함.

6. 직관적 사용 - 사용자가 기억해야 할 내용을 최소화하도록 설계해야 함.

7. 효율적, 유연 - 초보자와 숙련자 모두를 위한 유연한 인터페이스를 제공해야 함.

8. 심미적, 간결 디자인 - 불필요한 정보와 요소를 제거하고 단순화된 디자인을 유지해야 함.

9. 오류 파악, 수정 - 오류 메시지는 문제를 정확히 설명하고 해결 방법을 제안해야 함.

10. 충분한 도움말 - 사용자가 필요할 때 찾을 수 있는 도움말과 문서를 제공해야 함.

---

느낀 점

 

기획 과정에서 명료하게 뭔가 워크프레임을 이용하지 못함

개념을 실무로/실습으로 가져오질 못함

실습 다시 해볼 것

걱정되는 것은 이렇게 배운 것들을 내가 제때 잘 활용할 수 있을지 고민이다.

 

UX의 핵심은 '사용자 공감'이라고 말만 배웠었는데 오늘 수업으로 조금 깨닫게 되었다.

유저를 안심시키는 것이 프디의 몫이라는 생각이 들었고, 이를 위해서 내가 유저가 되어보면서 직접 공감하는 태도가 필요하며 공감을 통해 얻은 인사이트가 프로덕트 디자이너의 시야를 여는 것이라고 느꼈다.