UXUI 디자인 입문 실무 프로세스 3-2

전반적인 프로세스 먼저 알려주고, 세부적으로 알아야할 사항들을 자세하게 말씀드릴게요~ 쌤왈!

 

그럼 파이팅 3-2 해보자!

 

디자인 프로세스에서 각각 폭넓게 기획 디자인 개발을 하는데,

디자이너는 각 단계에서 어떤 일을 하는지 알아보자.

 

기획

 

문제정의

 

문제정의가 가장 중요하다고 지난시간에도 얘기했던게 기억나나요? 네!

문제정의를 올바르게 해야 문제점이 뭔지 알고, 해결(솔루션)을 할수있으니까요.

 

PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정함!

사실 회사에따라서 디자이너가 참여하기도 하고, 비참여지만 여기서부터 디자이너가 참여하는걸 추천한다. 쌤왈~

 

아이데이션

 

앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그중에서 적절한 솔루션을 선택

필요에 따라 러프한 솔루션 스케치 진행

 

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

 

 

프로덕트 스펙 문서 작성

• 솔루션이 구체화 되었다면 디자인전에 상세하게 글로 적어보는거야!
• 2~3일 걸릴수 있어~
• 이 솔루션을 보고 개발자가 미리 준비할 수 있고.
• 솔루션에 말이 안맞는 부분은 없는지, 내가 놓친부분이 없는지를 알 수 있게 됌.
• 회사에따라 생략, PO/PM직군이 작성.

디자인

 

초안디자인

디자인툴을가지고 디자인하는 과정

초안이기때문에 초안바탕으로 피드백받을거니까

디테일보다 전체적인 뷰~ 사용자 여정과 ux 프로젝트 집중

프로덕트 스펙문서에서 놓친 엣지케이스없는지 

 

피드백

논의한대로 디자인 반영 잘되었는지 공유하고 피드백 받고,

초안 공유뿐만아니라 프로토타입까지 공유.

 

최종 디자인 확정 및 핸드오프

피드백을 반영해서 최종 디자인하고 확정하고, 엔지니어에게 공유

엔지니어에게 공유한느 것을 핸드오프.

핸드오프과정에서 가이드를 함께보내기도한다.

 

*핸드오프 디자인을 개발 할수 있도록 엔지니어에게 전달하는 것.

 

핸드오프할때 디자인한 화면만 전달하지 않는다.

엔지니어가 잘 이해하고 있어야 제품으로 개발될수 있으니 다음 내용 포함해야함

 

유저플로우

단일화면 하나 -> 액션 연결과정 잘 드러너야함.

 

유즈케이스

상황에따라 화면정의

회원가입이라는 단일화면에 텍스트 필드를 그린다. 액션을함에따라 다이나믹하게 달라진다.

정상케이스 오류케이스 타임아웃 등 다 놓치지않고 정의도 해줘야함

 

반응형레이아웃

앱 웹 디바이스 각각 다른 스크린.

회사 기준으로 하나의 화면으로 정의를 하는데 디바이스에 맞게 줄어들고 늘어나야되는지.

 

개발

정확하게 개발되었는지 디자인 QA 

작업은 데스크톱으로 하지만 모바일에서 보여져야한다면 모바일 확인 추천 쌤왈~

앱이라면 안드로이드,아이오에스 모두 확인하는 것이 좋다.

 

제품 배포되고 디자이너 역할도 마무리가 된다.

 

제품이 만들어지는 과정에서 디자이너 역할에 대해 살펴봤다.

 

 

프로덕트 스펙 문서 작성하기

PRD , 제품요구사항 정의서라고 부른다.

 

프로덕트 스펙 왜 필요? 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드하는 역할

 

어떤 내용이 들어가나요? 

어떻게 기획이 되었고 기획배경 솔루션과 기능요구사항 실험해서 검증 할건지를 담고있다.

 

기획, 디자인, 개발 각 분리 된 문서말고 하나의 문서를 작성하는 것을 추천하며 문서가 파편화되있으면 보기 불편

 

파편화가되어있더라도 한문서에 URL 첨부해서 모든사람이 보게하기 최대한!!!

 

1. 기획배경&문제정의

문제발견과정

문제로정의이유 

문제의원인

누가 이문제에 영향 받는지

2. 솔루션 설명단계 (디자이너 역할)

페르소나(사용자정의)

사용자 시나리오

기능별 주요 특징 & 요구사항 (세부적으로)

예외 사항 및 엣지 케이스 정의 (생각하지못했던 케이스) @태그 엔지니어 이런포인트가 우려되는데 개발될수있을까요?

완성도 높은 제품만들수있다.

최종시안

 

3. 실험 설계

문제정의 - 솔루션 - 실험(Test)

데이터에널리스트 피엠피오가 작성하면 좋다.

 

4. 예상 일정

예상일정이 포함되야해 제품은빠르게 검증하면 좋아 스프린트~!!! 

 

프로덕트문서는 계속 업뎃되야하고, 쌤이 올려주신 템플릿 참고하기

 

좋은 디자인, 최종 시안, 피드백, 고도화

 

디자인과 피드백 거듭되는 수정

기획배경이나 맥락을 잘 설명

 

 

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

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

 

예시

 

 

 

 

오후가 되니 또 졸리기 시작한다 ㅠㅠ 파이팅!!!!