[UX/UI 실무] 프로덕트 제작 디자인 프로세스 & 디자인 공유하고 피드백 받기 & 프로덕트 스펙 문서 작성

 

디자인  프로세스

---

1️⃣ 기획

1. 문제 정의
   • PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정합니다.
   • 회사에 따라 문제 정의 단계에서 디자이너가 참여하기도 하고, 참여하지 않고 따로 PO/PM이 문제를 선정해 공유하기도 합니다.
2. 아이데이션
   • 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그중에서 적절한 솔루션을 선택합니다.
   • 필요에 따라 러프한 솔루션 스케치를 진행하기도 합니다.
     • 솔루션 스케치
       
     • 보통 아이데이션 단계에서 그리는 솔루션 스케치는 기획과 아이디어가 잘 보이도록 와이어프레임의 형태로 그립니다.
3. 프로덕트 스펙 문서 작성
   • 디자인에 들어가기 전, 문서에 솔루션에 대한 상세 내용을 글로 먼저 적어봅니다.
   • 디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 장점이 있습니다.
   • 회사에 따라 생략되거나 PO/PM 직군이 맡아서 하기도 합니다.

솔루션 스케치 : 보통 아이데이션 단계에서 그리는 솔루션 스케치는 기획과 아이디어가 잘 보이도록 와이어프레임의 형태로 그립니다.

 

2️⃣ 디자인

1. 초안 디자인
   • 피그마나, 스케치 등의 디자인 툴로 솔루션을 디자인합니다.
   • 디자인 디테일보다는 전반적인 사용자의 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 살핍니다.
2. 피드백
   • 기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들에게 공유하고 피드백을 받습니다.
   • 솔루션의 성격에 따라 피그마 프로토타이핑이나 프로토파이 같은 프로토타입 툴을 사용하기도 합니다.
3. 최종 디자인 확정 및 핸드오프
   • 피드백을 초안에 반영하여 최종 디자인을 확정합니다.
   • 확정한 최종 디자인을 엔지니어에게 공유하고 개발이 원활히 진행될 수 있도록 돕습니다.
   • 필요에 따라 가이드를 함께 작성해 전달하기도 합니다.
   • 핸드오프란?
     • 핸드오프는 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것을 의미해요.
     • 디자이너의 의도를 엔지니어가 잘 이해해야 제품이 잘 구현될 수 있겠죠?
     • 디자인을 공유할 때 다음의 내용을 포함해 함께 전달하는 것이 좋습니다.
       1. 유저 플로우
          • 처음 시작하는 화면은 어디이고 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성해 보세요.
       2. 유즈 케이스
          • 상황에 따른 화면 정의를 말해요.
          • 예를 들어, 회원가입 화면에서는 정상 입력, 입력값 오류, 입력 가능 시간 초과 등의 다양한 상황이 생길 수 있어요. 모든 케이스에 달라지는 화면을 놓치지 않고 정의해 주어야 합니다.
       3. 반응형 레이아웃
          • 대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응합니다.
          • 아주 작은 스크린 크기나 특별한 스크린 크기에 디자인이 어떻게 표현되어야 하는지 가이드를 주는 것이 좋습니다.
          • 가이드 예시
            
             🔗 참고문서: 디자인 핸드오프에서 지켜야 할 3가지

 

3️⃣ 개발

디자인 QA

• 개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA를 합니다.
• 최대한 사용자와 비슷한 환경으로 테스트하세요.
• 앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인하는 것이 좋습니다.

 

 

디자인 공유하고 피드백 받기

---

좋은 피드백을 받기 위해선 디자인을 잘 공유하는 것이 중요합니다.

• 디자이너의 업무의 대부분은 디자인과 피드백, 거듭되는 수정으로 이루어집니다.
• 기획 배경과 맥락을 잘 이해해야 좋은 피드백이 나올 수 있습니다.
• 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달하세요.
  
  

✅ 디자인 피드백을 요청할 때 포함하면 좋을 것

• 배경
  • 해당 프로젝트를 기획하게 된 배경을 설명합니다.
  • 구체적인 데이터와 가설을 더하면 좋습니다.
• 솔루션의 의도
  • 가설에서 어떠한 방향성을 잡고 디자인했는지 설명합니다.
  • 시각적으로 강조하고 싶었던 부분이나 중요하게 생각한 부분이 있다면 함께 적습니다.
• 필수 리뷰어
  • 다수에게 디자인을 공유할 땐 꼭 피드백을 받고 싶은 사람을 지정하는 것이 좋습니다.
  • 디자인한 화면으로 영향을 받는 곳과 연관된 사람이 있다면 참조CC하세요.
• 참고 문서
  • 프로덕트 스펙 문서를 함께 첨부하면 전반적인 프로젝트를 이해하는 데에 도움이 됩니다.
  • 디자인 파일도 함께 공유하면 다른 디자이너들의 도움을 받을 수도 있어요.
  • 이해를 돕기 위해 프로토타입을 함께 공유하는 것도 좋습니다.
• 피드백 기한
  • 제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유를 가지세요.
  • 만일, 일정이 촉박하다면 피드백을 받고 싶은 기한을 함께 표시하는 것이 좋습니다. 피드백을 주는 사람도 일정을 함께 고려할 수 있으니까요.
    
    
    

디자인 피드백 요청 예시

프로덕트 스펙 문서

---

프로덕트 스펙은 제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드예요. 회사에 따라서 PRD(Product Requirements Document, 제품 요구사항 정의서)라고 부르기도 해요.

✅ 프로덕트 스펙이 왜 필요한가요?

• 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드하는 역할을 합니다.

✅ 어떤 내용이 들어가나요?

• 기획 배경과 솔루션, 기능 요구사항, 실험 계획 등을 담고 있어요.
• 가능한 한 기획, 디자인, 개발에 필요한 모든 내용을 적는 것이 좋습니다. 문서가 여러 개로 파편화되어 있다면 URL을 첨부해서 한 곳에서 볼 수 있도록 해주세요.

• 1. 기획 배경 & 문제 정의 : 기획하게 된 배경을 짧게 설명하고 사용자의 문제를 정의합니다. 문제 정의에는 아래의 내용들이 포함되어야 해요(문제 바탕으로 솔루션을 만들 것이기 때문, 솔루션이 어떤 배경에서 나오게 되었는지 감정적으로 깊게 이입하지 않으면 솔루션을 각자 똑같이 이해할 수 없게 된다). 
     *문제 발견 과정
     *문제로 정의한 이유
     *문제의 원인
     *누가 이 문제에 영향을 받는지
     
     
  2. 솔루션 설명 (디자이너의 역할이 가장 중요한 부분) : 만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명합니다. 솔루션 설명에는 아래의 내용들이 포함되어야 해요. (보통 프로젝트 나머지 스펙 부분들은 PO나 PM이 채워주고, 솔루션 설명 단계만 디자이너가 작성) 작성하면서 내용들을 리마인드 하고, 놓친 부분은 없는지 생각을 정리할 수 있다.
     • 페르소나 - 사용자의 페르소나는 어떤 모습인지 (상상할 수 있게) 정의
     • 사용자 시나리오 - 우리 솔루션을 사용자는 어떠한 시나리오로 쓰게 될지를 적기
     • 기능별 주요 특징 & 요구사항 - 개발이 될 때는 어떤 내용들이 포함되어야 하는지 세부적으로 피처별로 요구사항과 특징들을 적는다. 
     • 예외 상황 및 Edge Case 정의 - 디자인을 하면서 우려되는 포인트나 생각하지 못한 케이스들이 나올 가능성에 대해 적기 (적고 엔지니어를 @태그해서 질문한다. '이런 포인트들이 우려가 되는데 개발상 구현할 수 있을까요?'라고 먼저 문서에 작성을 해서 커뮤니케이션 하게 되면 놓치는 부분 없이 조금 더 완성도 높은 제품을 만들수 있다.)
     • 최종 시안 - 위에 사항들을 문서로 다 작성을 하면 최송 시안을 디자인하고, 최송 시안 URL을 문서에 같이 첨부한다.
       
       
  3. 실험 설계  : 솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지에 대한 계획을 적습니다. (데이터 애널리스트가 있으면 그 분이 적고, 없으면 PM OR PO가.. 그럼에도 디자이너는 어떻게 실험이 진행되겠다 정도는 알고 있는 것이 좋다.)
     • 실험 가설
       • 문제 해결을 통해 만들어 내고자 하는 결과
     • 실험 방식
     • 결과 평가
       • 문제가 해결되었는지 판단할 수 있는 방법
     • 실험 기간
       
       
       
       
       
  4. 예상 일정 : 프로덕트 스펙에는 예상 일정을 꼭 포함해야 해요. 작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은 리소스를 효율적으로 쓰기 위한 시작점이기 때문에 매우 중요합니다. ('스프린트' 안에서 개발을 하겠다라는 것들이 가시적으로 보여야 한다.)
     • 프로덕트 스펙 초안 작성 완료 예상 일정
     • UI/UX 디자인 최종 시안 제작 완료 예상 일정
     • 개발 분야별 예상 일정
       • 프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성되어야 합니다.
     • 배포 목표 일정
       
       
       

✅ 프로덕트 스펙 문서는 계속해서 업데이트되어야 합니다.
한 번 작성한 뒤 다시 보지 않는 문서가 아니에요. 기획 초기에 만들기 시작해 기능이 배포되고 실험이 종료될 때까지 끊임없이 업데이트하고 관리되어야 합니다.

 

구글 템플릿 참고 하기

https://docs.google.com/document/d/e/2PACX-1vQUR9p8Iitgh4JSoEZ553xjq9nKVw_iFnlovhL7JdgLQIcQG708IXbxjdFamxUEbEpWm07HkqflMrPl/pub