안녕하세요.

오늘은 개발협업에 대해 스터디한 내용을 쓰려고 합니다.

개발자와 소통하고 개발적 관점과 사고 방식을 알아보도록 하겠습니다.

DIKW 피라미드구조의 이해와 개발자 사고 방식 살펴보도록 하겠습니다.

DIKW 피라미드구조의 이해

개발자 사고방식 알아보기

작은 문제부터 확실하게, 효율적으로

✓다이나믹프로그래밍이란?

대규모의 복잡한 연산이 필요할때, 메모리 공간의 효율성을 비약적으로 향상시키는 방법으로, 큰 문제를 작은 단위로 쪼개어 나누고, 부분 문제들의 답을 재사용해 최종 문제를 해결하는 방식으로 실행됩니다.

✓다이나믹프로그래밍(이하DP)의 작동 조건

최적부분구조(Optimal Substructure) 큰 문제를 작은 문제로 나눌 수 있으며, 작은 문제의 답을 모아서 큰 문제를 해결할 수 있습니다.

중복되는 부분 문제(Overlapping Subproblem) 반복 되어 나오는 동일한 작은 문제의 답은 항상 같습니다.

오픈 라이선스의 이해

Git과 GitHub

C:\workspace 폴더 이동- 폴더 빈공간우클릭-추가옵션표시클릭-Open Git Bash here 실행

1. 터미널 입력창에 본인 닉네임입력 git config --global user.name “User name”

2. 입력 후 다시 본인 이메일 입력 git config --global user.email “example@email.com”

3. 입력 후 설정 확인 git config --list 닉네임, 이메일을 잘못 입력했다면? git config --global --unset user.name 혹은

git config --global --unset user.email 을 입력하여 삭제 후 다시 입력할 수 있습니다.

1. C:\workspace\ 폴더 이동 후 우클릭-Open git bash here 혹은, git bash 터미널 입력창에 cd c/workspace/ 입력 후 엔터 청록색의(main)이 표시 된다면 연동이 잘된 것입니다.

2. 명령어 순서대로 입력 git add . 

add 뒤에 공백넣고 입력 git status

(상태확인, 선택사항) git commit -m ‘0213’

(메시지 내용은 자유) git push 순서대로 입력 

3. 첫 git push시 Connect to GitHub 요청 Sign in with your browser로 쉽게 연결 가능

4. git bash로 돌아와서 git push 입력후 엔터

마치며

개발자의 협업과정에서 필요한 git 과 gitHub에 대해 알아보는 시간이었습니다.

안녕하세요.

오늘은 PM이 데이터를 보는 관점에 대해 스터디한 내용을 쓰려고 합니다.

데이터 보는 관점 깨뜨리기, 추천 알고리즘의 종류, 대표적인 추천 알고리즘 원리, 데이터 통계 & 가설 검정, 통계의 함정과 대처에 대해 알아보도록 하겠습니다. 

데이터 기반 사고

데이터 보는 관점 깨뜨리기

넷플릭스의 추천 알고리즘은 중립적이지 않다

Yes와 No는 대부분 동시에 존재한다. ‘성공 기준을 무엇으로 정의하느냐’에 따라 Yes와 No의 다이아몬드 구조 설계

추천 알고리즘의 종류

추천 알고리즘에 사용되는 데이터 특성

데이터를 읽고 판단할 줄 알아야 적합한 추천 알고리즘과 콘텐츠 제공이 가능

콘텐츠 기반

콘텐츠 기반 유저의 과거 기록을 바탕으로 다음 행동 패턴을 예측하여 추천 마켓 이용기록

예시) 한 유저의 마늘 – 고추 – 채소 – 버섯 구매기록과 유사한 특성의 제품 유기농 채소, 건강식품 등을 추천 내가 지금까지 소비한 것과 가장 유사한 제품을 추천

협업 필터링

유저의 행동 패턴과 유사한 유저들의 선택을 기반으로 추천 마켓 이용기록

예시) 마늘 – 고추 – 채소 – 버섯 구매기록과 유사한 유저가 주로 구매한 물품 고기, 일회용 식기, 음료 등을 추천 나와 비슷한 사람들이 함께 선택한 제품을 추천

데이터 통계 & 가설 검정

데이터기반 사고 – 가설 수립 – 가설 검정 – 추후 제언

과학자들은 자신이 틀렸기를 바란다.

설득에서 검정까지, 사고의 전환 | 관련 영상 – Part1. 페르미 역설 – 과학자들은 자신들이 틀렸기를 바랍니다.

귀무가설과 대립가설의 정의

귀무가설과 대립가설은 통계학적 가설 검정을 시도할 때 주로 쓰입니다.

대립가설(대안가설):

새로운 주장 근거 데이터가 기존의 사실과 유의미한 차이나 극명한 효과, 관계가 존재 할 것이라는 가설

귀무가설(영가설):

기존의 사실과 큰 차이가 없거나 효과가 무의미, 혹은 우연에 의해 발생 되었다는 귀(歸)돌려보내다 무(無)없던 것으로 라는 뜻의 가설

통계분석의 관계성 판단

유의미하다는 기준은 어떤 방식으로 정해야 될까?

각 계산 방법을 공부하는 것이 아니라, 어떤 근거로 산출 되는지 파악할 수 있는 것이 중요

통계의 함정과 대처

유저의 거짓말, 생존자 편향, 100%의 신호, 이상치

문제는 데이터를 보이는 그대로 믿어버릴 때 주로 발생 수집한 데이터는 많은 것을 내포 하고 있지만, 표면적인 것과 다른 맥락을 숨기고 있는 경우도 많다

유저는 거짓말을 의도한 걸까?

• ‘와, 이거 정말 좋네요. 꼭 쓸게요’ 그들은 나타나지 않았다. – 토스 피드: 우리는 사용자를 믿지 않는다

• 인터뷰 진행자의 열정, 표정 및 몸짓과 같은 비언어적 신호를 통한 요구적 응답 – 인터뷰 진행자 편향

• 나쁜 습관은 과소응답, 좋은 습관은 과대응답하는 현상 – 사회적 바람직성 편향

생존자 편향

‘남아 있는 사람들’의 데이터

질문을 던지는 습관 데이터에 등장하지 않는 사람은 누구일까?

• 불편해서 시도조차 하지 않는 유저

• 가입만 해보고 사용을 하지 않는 유저

• 바라는 점이나 기대감보다 실망감을 크게 느낀 유저

• 설문이나 응답을 어디에 남기는지 인지하지 못한 유저 이런 유형의 유저가 빠져 있는 데이터는 낙관적인 착각을 불러오기 쉽다.

신뢰도 100%의 결과는 좋은 신호가 아니라 경고일 수 있다.

서비스에서 ‘완벽한 결과’는 축하보다 질문이 먼저 나온다.

• 모든 응답에 반대 의견이 없다

• 모든 유저가 만족하고 있다

• 0.01%의 오류 데이터도 없다

데이터 기반사고의 중요성 

일상 속에서도 몇가지의 사실 데이터를 기반으로 다양한 사고를 떠올려보고,

- 데이터 기반 사고 다양한 시도와 가능성에 대해서 끊임 없이 상상해 보신다면,

- 가설 수립 지금의 귀무가설을 기각 할 수 있을만한 모든 의심을 품어보고 해결하는 연습이 될 거예요!

- 가설 검정 기회가 된다면, 실제로 행동에 옮겨보고, 현실적 한계점을 개선하며 좋은 성장 커브를 가지게 되길 바라겠습니다!

- 추후 제언

나의 주장이 틀렸다는 것을 증명하는 것에 실패 해보자

주제: 강의 완주까지 적극적인 참여를 한 수료생은

대립 가설: AI PM으로서의 역량 상승이 유의미하게 것이다.

귀무 가설: 완주 여부와 관계 없이 AI PM 역량에는 차이가 없을 것이다.

• 귀무가설이 정말 기각되었나?

• 결과는 시간이 지나도 유지 될 수 있는가?

• 모든 사람에게 동일하게 적용 가능한가?

마치며 

나의 주장이 틀렸다는 것을 증명하는 것에 실패해보는 것을 생각해보는 시간이었습니다.

안녕하세요.

오늘은 화면설계서에 대해 스터디한 내용을 쓰려고 합니다.

화면 설계서는 디지털 서비스나 애플리케이션의 UI(User Interface) 구성과 기능을 해야 하는지 정리한 문서입니다.

기획자, 디자이너, 개발자 간 원활한 협업을 돕는 역할을 하고 화면의 레이아웃, 네비게이션 흐름, 인터랙션, 주요 기능 등을 상세히 정리하여 개발과 디자인의 기준이 되는 문서 입니다.

기획자, 디자이너, 개발자 간 원활한 협업을 돕기 위해 작성되며, 서비스의 화면 구조와 주요 기능을 체계적으로 정리하는 역할을 하는 화면 설계서에 대해 알아보도록 하겠습니다.

화면 설계

화면 설계의 중요성

1) 개발과 기획의 원활한 협업을 위한 핵심 문서

2) 사용자 경험(UX) 개선에 기여

3) 개발 리소스 및 비용 절감

4) AI 서비스 기획에서의 추가 고려 요소

5) 사례 분석 : 화면 설계가 미비할 경우 발생하는 문제점

• 사례 1 : 요구사항이 제대로 반영되지 않음

• 사례 2: 화면 간 일관성이 부족함

• 사례 3 : 개발과 기획 간 커뮤니케이션 오류 발생

화면 설계서 작성시 고려사항

1) 사용자의 행동 패턴 분석

2) 직관적인 네비게이션 구성

3) 피드백과 오류 메시지 설계

4) 기술적 제약 사항 고려

화면 설계서 작성하기

1. 파일명

2.표지

1) 문서 제목

2) 프로젝트 정보 (부제목 또는 설명)

3) 문서 메타데이터 (Document Metadata)

3. Version History

4. 화면 목록 및 네비게이션 구조

네비게이션 구조(Navigation Structure) 정의하기

• 네비게이션 구조란 네비게이션 구조는 사용자가 시스템 내에서 어떻게 이동할 수 있는지를 시각적으로 표현한 구조도입니다. 이는 메뉴 설계와 사용자 경험(UX)에 중요한 영향을 미치므로, 직관적이고 논리적인 구조를 설계해야 합니다.

• 네비게이션 구조 설계 시 고려해야 할 요소

✓ 메인 메뉴와 서브 메뉴 구분

✓ 사용자 이동 경로 정의

✓ 화면 전환 방식 고려

✓ 백버튼(뒤로 가기) 및 히스토리 관리

✓ 네비게이션 구조 예시

화면 흐름 정의 및 플로우차트

플로우차트 작성 시 유의할 점

① 프로세스를 최대한 단순화 

② 분기점(Decision)을 명확하게 정의

③ 예외 처리 흐름을 반드시 포함

④ 개발 및 디자인 팀과 협업하여 검토 

마치며

기획자, 디자이너, 개발자 간 원활한 협업을 돕는 역할을 하고, 화면의 레이아웃, 네비게이션 흐름, 인터랙션, 주요 기능 등을 상세히 정리하여 개발과 디자인의 기준이 되는 문서인 화면 설계 개념에 대해 알 수 있었습니다.

안녕하세요.
오늘은 비즈니스 모델 캔버스에 대해 스터디한 내용을 적어보려고 합니다.

비즈니스 모델 캔버스를 통해 서비스 구조를 깊이 있게 이해함으로써 기업 전략과 서비스 기획 역량의 시너지를 극대화 시킵니다.

비즈니스 캔버스 세부 요소를 살펴보고 유형별 케이스를 알아보도록 하겠습니다.

비즈니스 모델 캔버스

비즈니스 모델

1. 고객 세그먼트

누구를 위해 가치를 창조해야 하는가? 누가 우리의 가장 중요한 고객인가?

조직은 하나 이상의 고객 세그먼트에게 상품이나 서비스를 제공합니다.

2. 가치 제안

고객에게 어떤 가치를 전달할 것인가?

우리가 제공하는 가치가 고객이 처한 문제점을 해결해주는가?

제각기 다른 고객 세그먼트에게 어떤 상품이나 서비스를 제공하는가?

3. 채널

각각의 고객 세그먼트들은 어떤 채널을 통해서 자신에게 가치가 전달되길 원하는가?

그들에게 어떻게 다가가는가?

채널은 어떤 기준으로 통합돼 있는가?

어느 채널이 가장 효과적인가?

어느 채널이 가장 비용 효율적인가?

채널과 고객을 이한 업무는 제대로 통합되어 있는가?

4. 고객관계

각각의 고객 세그먼트들은 어떤 방식의 고객관계가 만들어지고 유지되기를 원하는가?

우리는 어떤 고객관계를 확립했는가?

다른 비즈니스 모델 상의 요소들과는 어떻게 통합되는가?

• 고객과의 관계는 각각의 고객 세그먼트 별로 특징적으로 확립되고 유지됩니다.

5. 수익원

고객들은 어떤 가치를 위해 기꺼이 돈을 지불하는가? 현재 무엇을 위해 돈을 지불하고 있는가?

현재 어떻게 지불하고 있는가? 고객들은 어떻게 지불하고 싶어하는가?

각각의 수익원은 천제 수익에 얼마나 기여하는가?

6. 핵심 자원

물적자원, 지적 자산, 인적 자원, 재무 자원

7. 핵심 활동

우리의 밸류 프로포지션은 어떤 핵심 활동을 필요로 하는가?

공급 채널을 위해선 어떤 활동이 필요한가?

고객관계를 위해선, 수익원을 위해선 어떤 활동이 필요한가?

8.핵심 파트너십

누가 핵심 파트너인가?

우리의 핵심 공급자는 누구인가?

파트너로부터 어떤 핵심자원을 획득할 수있는가?

파트너가 어떤 핵심활동을 수행하는가?

9.비용 구조

우리의 비즈니스 모델이 안고 가야 하는 가장 중요한 비용은 무엇인가?

어떤 핵심자원을 확보하는 데 가장 많은 비용이 드는가?

어떤 핵심활동을 수행하는 데 가장 많은 비용이 드는가?

패턴

• 언번들링 <-> 번들링
• 롱테일 하위 80% 80% <-> 파레토 상위 20% 80%
• 멀티 사이드 플랫폼
• 무료 비즈니스 모델

언번들링

• 고객관계 비즈니스
• 제품혁신 비즈니스
• 인프라 스트럭처 비즈니스가 혼재됨

롱테일

‘티끌모아 태산’ 이라는 개념을 바탕으로 상대적으로 판매 빈도가 적은 수많은 틈새상품의 판매에 집중하고 틈새 컨텐츠입니다.

• 생산수단의 민주화
• 유통의 민주화
• 수요와 공급을 연결시키기 위한 탐색비용 감소

멀티사이드 플랫폼

2개 또는그 이상의 별개이지만 상호의존적인 타깃그룹을 합한것입니다.

사례

당근의 사례

마치며

비즈니스 모델 캔버스를 통해 비즈니스를 더 깊이있게 들여다 볼 수 있었고 효율성과 가치에 따라 나누어 보면서 

비즈니스 모델 패턴에 필요한 핵심 자원을 알 수 있었습니다.

안녕하세요.

오늘은 SQL에 대해 스터디한 내용을 쓰려고 합니다.

SQL의 핵심은 데이터를 테이블 구조로 저장하고, 이 테이블 간의 관계를 활용하여 정보를 효율적으로 관리하고 검색하는 관계형 데이터베이스(RDB)를 다루는 것입니다.

SQL의 핵심 개념인 관계형 데이터베이스 (RDB)의 작동 원리 이해와  SQL의 핵심은 데이터를 테이블 구조로 저장하고, 이 테이블 간의 관계를 활용하여 정보를 효율적으로 관리하고 검색하는 관계형 데이터베이스(RDB)를 다루는 법에 대해 알아보도록 하겠습니다.

SQL

데이터 제어의 네 기둥 (CRUD) SQL은 데이터를 다루는 데 필요한 모든 기능을 제공하며, 이를 CRUD (Create, Read, Update, Delete)라는 네 가지 기본 작업으로 분류할 수 있습니다.

추출하고 싶은 데이터 (요건)을 정의하는 기본 구조

 • ( 어디에 ) = ‘FROMʼ이라는 명령어 뒤에 정의

• ( 조건 ) = ‘WHEREʼ이라는 명령어 뒤에 정의

• ( 필요한 항목 ) = ‘SELECTʼ라는 명령어 뒤에 정의위 세가지 요소들이 SQL 의 기본이라고 할 수 있습니다.

그리고 SQL 쿼리문은 이 요 소들을 아래 순서대로 나열해야 되는 규칙을 가집니다. 

구매 데이터에서 24년 4월 한달 간 데이터 추출

1.쿼리 결과를 년 4추출하기 월 한 위해 [달 간 실행] 데이터 추출버튼을 누릅니다

2.하단에 초록색 체크 표시는 정상 처리 될 때  뜹니다. 

3.하단에 쿼리 결과 표를 확인합니다.

대시보드 만들기

1.쿼리 결과에서 [다음으로 열기] →[Looker Studio]를 연결합니다. 

2.추출한 데이터 결과에서 컨트롤 필터로 [브랜드=네오체크]를 설정해 총 구매건 수, 구매액, 구매 유저 수, 구매 상품 판매 현황 데이터를 대시보드에 추가합니다.   

3.총 구매건 수(스코어 카드/order_id집계 구분), 총 구매액(스코어 카드/payment 합계), 구매 유저수(user_id집계구분), 구매 상품 판매 현황(표그래프, 구매액, 구매 유저수 (집계 구분) 측정 항목) 

4.컨트롤 필터로 브랜드 중 네오체크만 선택해주세요

마치며

빅쿼리로 데이터를 추출하여 루커 스튜디오와 연동하는 법을 알아보는 시간이었습니다.

안녕하세요.

오늘은 서비스 정책서에 대해 스터디한 내용을 쓰려고 합니다.

서비스 정책서는 서비스 운영과 사용자 경험의 일관성을 유지하기 위해 정해진 규칙과 지침을 정리한 문서입니다.

이는 회원 관리, 콘텐츠 운영, 보안, 커뮤니케이션, 법적 준수 사항 등을 포함하며, 기획자, 개발자, 운영자 등 모든 이해관계자가

참고해야 할 기준이 됩니다. 

정책서는 서비스 방향성을 명확히 하여 혼선을 방지하고, 사용자 신뢰도를 높이는 역할을 합니다. 또한, 법적 분쟁이나
운영상의 문제를 사전에 예방하고 원활한 서비스 제공을 지원합니다.

서비스 정책서

서비스 정책서의 역할

① 서비스 일관성 유지

② 기획 및 개발 효율성 향상

③ 법적 분쟁 및 규제 준수
④ 사용자 신뢰도 및 만족도 향상

⑤ 서비스 운영의 기준 제공

⑥ 변경 관리 및 서비스 개선 방향 설정

서비스 정책서는 서비스 운영의 핵심 기준이 되며, 사용자 경험의 일관성을 유지하고, 기획 및 개발 효율성을 높이며, 법적 문제를 예방하는 중요한 역할을 합니다. 또한, 사용자 신뢰도 향상, 서비스 운영 기준 제공, 변경 관리 지원 등을 통해 서비스의 지속적인 개선과 성장을 가능하게 합니다. 서비스 정책서를 체계적으로 관리하고 지속적으로 업데이트하는 것이 성공적인 서비스 운영의 필수 요소입니다.

정책서 작성을 위해 고려해야 하는 법률

1)관련 법령 (Legal Framework)

① 개인정보 보호법 (Privacy Laws)

② 전자상거래 및 소비자 보호법 (E-commerce & Consumer Protection Laws)

③ 저작권 및 콘텐츠 관리법 (Copyright & Content Regulations)

④ 광고 및 마케팅 규제 (Advertising & Marketing Laws)

2) 외부 환경 (생태계)

① 기술적 환경

② 플랫폼 정책 준수

3) 외부 환경 (경쟁사)

① 벤치마킹

② 정책 차별화

4) 내부 환경 및 리소스

① 인력 및 기술 리소스

② 운영 비용 고려

③ 법적 리스크 관리

서비스 정책서 구성 요소

서비스 정책서는 서비스의 운영 원칙을 정의하고 사용자 경험(UX) 및 법적, 기술적 요소를 종합적으로 고려하여 작성됩니다. 이를 통해 서비스가 일관되게 운영될 수 있도록 가이드라인을 제공하며, 모든 이해관계자가 참고할 수 있는 기준이 됩니다. 서비스 정책서는 다음과 같은 주요 요소로 구성됩니다.

1) 서론 (Introduction)

2) 회원 정책 (User Policy)

3) 콘텐츠 정책 (Content Policy)

4) 커뮤니케이션 정책 (Communication Policy)

5) 운영 정책 (Operational Policy)

6) 보안 및 개인정보 보호 정책 (Security & Privacy Policy)

7) 결제 및 환불 정책 (Payment & Refund Policy)

마치며

회원 관리, 콘텐츠 운영, 보안, 커뮤니케이션, 법적 준수 사항 등을 포함하여 생길수 있는 법적 분쟁에 관해 미리 준비할 수 있는 서비스 정책서 작성하는 법에 대해 알아보았습니다.

안녕하세요.

오늘은 기능 정의 및 IA설계에 대해 스터디한 내용을 쓰려고 합니다.

기능 정의(Function Definition)는 제품이나 서비스에서 제공해야 하는 기능과 동작을 상세하게 기술한 문서입니다.

정보 구조(IA, Information Architecture) 는 사용자가 디지털 제품(웹사이트, 애플리케이션 등)을 쉽고 직관적으로 탐색할 수 있도록 정보를 조직하고 구조화하는 과정입니다.

즉, IA는 사용자가 필요한 정보를 빠르게 찾고, 효율적으로 인터페이스를 사용할 수 있도록 돕는 역할을 합니다.

요구사항 정의 중 기능을 정의하고 정보구조를 만드는 법을 알아보도록 하겠습니다.

기능 정의(Function Definition)

기능 정의의 구성 요소

기능 정의(Function Definition)는 제품이나 서비스의 기능을 체계적으로 정의한 문서로, 모든 이해관계자가 참고할 수 있도록 명확하고 일관된 기준을 제공해야 합니다. 기능 정의를 효과적으로 작성하려면 기능 개요, 사용자 요구사항, 기능 동작 방식, 예외 처리 및 제약 사항 등의 핵심 요소를 포함해야 합니다.

1) 기능 개요 (Feature Overview) → PRD 문서로 대체 기능 개요는 해당 기능의 목적과 역할을 간략히 설명하는 부분으로, 기능이 왜 필요한지와 어떤 문제를 해결하는지를 정의합니다.

2) 사용자 요구사항 (User Requirements) → 요구코드로 추적 사용자 요구사항은 기능이 충족해야 하는 사용자의 기대와 필요를 설명합니다. 즉, 사용자가 이 기능을 통해 얻고자 하는 목표와 기대하는 행동을 정의하는 부분입니다.

3) 기능 동작 방식 (Function Behavior) → 기능 설명 부분에 기술 기능 동작 방식은 해당 기능이 실제로 어떻게 작동하는지 기술하는 부분입니다. 이를 통해 개발팀이 기능 구현의 흐름을 명확히 이해할 수 있습니다.

4) 예외 처리 및 제약 사항 (Exception Handling & Constraints) 예외 처리 및 제약 사항은 예상 가능한 오류 상황과 해당 오류가 발생했을 때 시스템이 어떻게 반응해야 하는지를 정의하는 부분입니다. 이 항목이 명확하지 않으면, 개발 중 예기치 않은 문제로 기능이 정상적으로 작동하지 않을 수 있습니다.

기능 정의서 작성 프로세스

기능 정의와 UX/UI의 관계

기능 정의(Function Definition)와 UX/UI(User Experience/User Interface) 설계는 밀접한 관계를 가지고 있습니다.

기능 정의가 제품의 ‘무엇을 할 것인가(What)’를 정의한다면, UX/UI 설계는 ‘어떻게 사용할 것인가(How)’를 결정하는 과정입니다. 기능 정의가 명확해야 UX/UI 디자이너가 사용자 중심의 직관적인 인터페이스를 설계할 수 있으며, 반대로 UX/UI 설계에서 얻어진 인사이트가 기능 정의를 보완하는 경우도 많습니다.

1) UX/UI의 기본 설계 방향을 결정

• 기능 정의에서 정의한 핵심 기능을 기반으로 UX 디자이너가 UI 구조를 설계합니다.

• 기능 요구사항에 따라 UI 요소(버튼, 입력 필드, 네비게이션 등)가 결정됩니다.

예시) 기능 정의 : “회원가입 시 이메일 인증이 필요함” ➢ UX/UI 설계 : “회원가입 완료 후, 이메일 인증 요청 팝업을 표시”

2) 사용자의 기대에 부합하는 인터페이스 설계 가능

• 기능이 단순히 존재하는 것만으로는 충분하지 않으며, 사용자가 쉽게 접근하고 사용할 수 있도록 설계 되어야 합니다.

• 기능 정의를 기반으로 UX/UI 설계를 진행하면서, 사용자의 기대에 맞게 UI가 조정됩니다.

예시) 기능 정의 : “검색 기능에서 키워드 입력 시 자동 완성 기능 제공” ➢ UX/UI 설계 : “검색창 아래에 추천 검색어 리스트를 실시간으로 표시”

3) 기능 간 연계 및 사용자 플로우 정의

• UX/UI 설계는 기능 정의에서 정의된 여러 기능 간의 연계를 고려하여 사용자 플로우를 만듭니다.

• 기능이 단독으로 존재하는 것이 아니라, 전체적인 사용 흐름 속에서 자연스럽게 연결되도록 설계합니다.

예시) 기능 정의 : “상품 상세 페이지에서 장바구니에 추가하는 기능 제공” ➢ UX/UI 설계 : “장바구니 버튼을 클릭하면, 우측 하단에 ‘장바구니에 추가되었습니다’라는 피드백 메시지 표시”

4) 예외 처리 및 오류 메시지 설계

• 기능 정의에서는 예외 처리 조건을 정의하지만, UX/UI에서 이를 어떻게 사용자 친화적으로 보여줄 것인지가 중요합니다.

• UX/UI 설계에서 오류 메시지를 직관적으로 제공해야 사용자가 문제를 쉽게 이해하고 해결할 수 있습니다.

예시)기능 정의 : “비밀번호 입력 시 8자 이상이 아닐 경우 오류 발생” -> UX/UI 설계 : “비밀번호 입력창 아래에 ‘비밀번호는 최소 8자 이상 입력해야 합니다’라는 메시지를 붉은색으로 표시”

IA(Information Architecture)란

1) IA의 핵심 요소

• 콘텐츠 분류(Content Organization) – 정보의 그룹화 및 계층 구조 설정

• 내비게이션 설계(Navigation Design) – 사용자가 콘텐츠를 찾을 수 있도록 경로 제공 • 검색 시스템(Search System) – 사용자가 원하는 정보를 검색할 수 있도록 지원

• 레이블링(Labeling) – 버튼, 메뉴, 카테고리의 명칭을 직관적으로 정의

• IA는 “사용자가 원하는 정보를 쉽게 찾도록 돕는 설계”입니다.

2) IA의 핵심 역할

① 사용자 경험(UX) 최적화

② 정보 접근성 향상

③ 사용자 경험(UX) 최적화

④ 검색 효율성 증대

⑤ 개발 및 디자인 효율성 향상

IA 설계의 주요 요소

1) 정보 구조(Information Organization)

• 정보를 논리적으로 분류하고 그룹화

• 계층 구조를 정의하여 사용자가 쉽게 정보를 찾을 수 있도록 설계

예시)이커머스 사이트 정보 구조 예시 (홈 > 의류 > 남성복 > 아우터 > 패딩)

2) 내비게이션 설계(Navigation Design)

• 사용자가 원하는 정보를 쉽게 탐색할 수 있도록 메뉴, 카테고리, 경로를 설계

• 메뉴바, 햄버거 메뉴, 사이드바, 퀵링크 등을 통해 내비게이션 경로 제공

예시 )잘 설계된 내비게이션 → “홈 > 카테고리 > 상세 페이지”로 자연스럽게 이동 가능

잘못된 내비게이션 → “홈 > 상세 페이지”로 바로 연결되면 사용자가 맥락을 이해하기 어려움

3) 검색 시스템(Search System)

• 사용자가 직접 검색할 수 있도록 검색창과 필터링 기능 제공

• 태그(tagging), 추천 검색어, 자동완성 기능 추가

예시) 네이버 – “실시간 인기 검색어, 자동완성 검색어 제공”

유튜브 – “추천 검색어 및 카테고리 기반 검색 결과 제공”

4) 레이블링(Labeling)

• 버튼, 메뉴, 카테고리의 이름을 직관적으로 설정

• 사용자가 혼동하지 않도록 일관된 명칭 사용

예시) “문의하기” → 고객이 이해하기 쉬운 버튼 명칭 

“도움 센터” → 어디로 연결되는지 불분명

IA설계사례

마치며

기능을 정의하고 IA설계를 왜 해야하는지 어떻게 작성해야 하는지 어떤 내용을 작성해야 하는지를 알게 되었습니다.

기능 정의가 명확해야 UX/UI 디자이너가 사용자 중심의 직관적인 인터페이스를 설계할 수 있다는 것을 알게 되었습니다.

안녕하세요.

오늘은 PRD (제품 요구사항 정의서) 에 대해 스터디한 내용을 쓰려고 합니다.

PRD(제품 요구사항 정의서) 는 개괄적으로 정리하는 문서로 투자자 경영진에게 보고하기 위해 정리한 문서입니다.

내부적인 사람들, 개발자, 디자이너, QA 가이드를 제공한다 용도별 각각 다르게 활용될 수 있고, 제품단계, 개발단계에서 어떤

요구사항을 확인하기 위한 기능인지 합의를 도출하는 중요한 문서입니다.

PRD(제품 요구사항 정의서) 핵심 구성요소와 작성법에 대해 알아보도록 하겠습니다.

PRD (제품 요구사항 정의서)

PRD(Product Requirements Document)는 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로 제품 개발 프로세스 전반에 걸쳐 필수적인 중요 문서입니다.

• 배경 --백로그 아이템의 맥락 ,문제점, 기회 등
• 목표 -- 이탈율을 높이는 목표 , 템플릿을 강화 다양한 템플릿, 템플릿 100개 만들기를 함 그 지표가 올라감 템플릿을 많이 만들면 페이지 이탈율이 올라갈 것이다 100개 선택하는 UI. 선택하게 해주는 UI가 필요함

주간회의 보고 전체 프로젝트의 투입인력들이 주간회의를 진행한다 모닝 스크럼을 진행합니다.

• 솔루션
• 의사 소통 계획 협업 방식을 어떻게 할거고 주요 산출물 관리를 어떻게 할거냐 이런것들에 대한 계획을 세웁니다.
• 마일스톤 데드라인 안에서 계획을 세우는 것

PRD 핵심 구성 요소

1) 배경(Background) : 문제 (Problems), 페르소나 (Persona)

백로그 아이템의 맥락, 문제점, 기회 등을 정성적·정량적 데이터로 설명합니다. 독자가 이해할 수 있도록 관련 자료를 첨부합니다.

2) 목표(Goals) : 핵심 성공 지표

SMART 원칙에 따라 구체적이고 달성 가능한 목표를 설정합니다. 목표 달성을 위한 하위 목표나 마일스톤도 포함합니다.

3) 솔루션(Solution) : 유저 저니맵, 솔루션 액션아이템, 기술 스펙 문서, 프로토타입 (Prototype)

문제를 해결할 주요 기능과 특징을 정의합니다. 솔루션의 장단점, 제한 사항, 사용자 경험 개선 방안을 포함합니다.

4) 의사소통 계획(Communication Plan) :  

이해관계자와의 소통 방법과 일정을 수립합니다. 정기적 진행 상황 공유와 피드백 수렴을 포함합니다.

5) 마일스톤(Milestones) : 일정 (Schedule), 리스크/ 의존성 (Dependency)

주요 작업 일정과 완료를 위한 세부 단계를 설정합니다. 일정 변경 시 반영하여 관리합니다.

6) 참조(References) : 

백로그 아이템과 관련된 문서나 자료를 첨부합니다. 프로젝트 배경과 근거를 강화하는 역할을 합니다.

PRD작성시 활용할 질문 리스트

1) 기본 질문

• 우리가 해결하고자 하는 문제는 무엇인가?

• 이 제품은 어떤 문제를 해결할 수 있는가?

• 최종 사용자는 누구이며, 그들의 주요 페인포인트는 무엇인가?

2) 기능 중심 질문

• 이 기능이 필수적인 이유는 무엇인가?

• 기능이 사용자 경험에 미칠 영향은 무엇인가?

• 각 기능의 성공 여부를 어떻게 측정할 것인가?

3) 프로세스 중심 질문

• 이 요구사항은 개발 프로세스에서 어떻게 구현될 것인가?

• 팀 간 협업에 필요한 추가 정보는 무엇인가?

PRD 작성 과정

1단계 : 사용자 문제 및 비즈니스 우선순위 정의

2단계 : 해결 방안 구체화

3단계 : 기능적 요구사항 명확화

4단계 : 이슈 기록 및 공유

5단계 : 지속적인 업데이트

PRD 작성 사례

1) 배경 (Background)

1-1. 문제 (Problems)

1-2. 페르소나 (Persona)

2) 목표 (Goals)

2-1. 핵심 성공 지표 (Measure of Success)

2-2. 가설 (Hypothesis)

3) 솔루션 (Solution)

① Team & Enterprise 사용자

② 시스템 및 서비스 관리자

③ Enterprise 계약 담당자

④ Live Chat SDK 사용자 (개발자)

⑤ Live Chat SDK 관리자

4) 의사소통계획

5)마일스톤

PRD 최종 점검 체크 리스트

1) 요구사항의 명확성 확인

2) 사용자 중심의 접근이 반영되었는가?

3) 비즈니스 목표 및 성공 지표 설정

4) 개발 및 디자인 팀과의 협업 고려

5) 프로젝트 일정과 리스크 관리 계획

PRD 문서의 활용

1) 제품 개발 프로세스 내에서 PRD 활용

2) 테스트 및 QA 과정에서 활용

3) 제품 출시 후 유지보수 및 개선에 활용

PRD의 지속적인 관리와 업데이트

PRD는 한 번 작성하고 끝나는 문서가 아니라, 제품 개발 및 운영 과정에서 지속적으로 업데이트되어야 합니다.

이를 위해 다음과 같은 관리 방안을 고려할 수 있습니다.

• 주기적인 리뷰

• 버전 관리 체계 도입

• 팀 내 커뮤니케이션 강화

PRD 문서 작성

마치며

제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로 제품 개발 프로세스 전반에 걸쳐 필수적인 중요 문서로 계속 업데이트가 필요한 PRD에 관해서 공부하고 실습하면서 계속 업데이트를 해야하는 중요한 문서라라는 것을 알 수 있었습니다.