작업방법 및 수행계획 수립
- UI/UX 개발에 적용할 프로세스를 수립하고 작업 수행에 필요한 지침, 방법 등을 작성할 수 있다.
- 수행 작업 별로 작업의 순서를 위해 작업의 우선순위를 정의하고 작업 간의 연관 관계를 도출할 수 있다.
- 프로젝트 수행 시 발생할 수 있는 위험요소를 식별하고 이를 관리하기 위한 계획을 수립할 수 있다.
프로세스 개념 및 유형
UI/UX 디자인 프로세스는 UI/UX를 개발하기 위해 필요한 과정 또는 구조이다. 일반적으로 프로세스란 주어진 목적을 위해 수행할 일련의 절차를 의미하는 것으로, 절차뿐만 아니라 투입 인력, 필요 기술을 통합하여 의미한다. 프로세스를 정의함을 문제 해결에 필요한 활동과 그들간의 순서를 명확하게 정의하는 것이다. 일반 소프트웨어 개발에 표준 개발 프로세스가 있듯이, UI/UX를 개발함에도 프로세스를 수립해야 한다. UI/UX 디자인 프로세스는 UI/UX를 개발하기 위해 필요한 절차, 절차 수행 방법, 절차를 통해 만들어낼 산출물등을 포괄적으로 정의한 것이다. 정형화된 표준 프로세스를 정의할 수 없지만, 실제 프로젝트에서 활용 중인 다양한 프로세스가 존재하므로, 이들을 참조하여 프로젝트 성격에 맞게 수정하여 사용해야 한다.
1. 폭포식 접근 프로세스
무엇을 달성한 것인가 분명하게, 어느 정도 달성되었는지를 분명히 알 수 있게, 목표 달성을 위해서 무엇을 해야 하는지를 명확하게, 현실적으로 적절하고 실현 가능하게, 적절한 시간과 시기가 설정되어야 한다는 것이 “SMART” 기법이다. 각각의 단계를 분리하여 고객의 최종 승인하에 다음 단계로 넘어가는 프로세스이다. 현재 수행중인 단계를 명확하게 파악할 수 있는 장점이 있는 반면 승인이 완료된 이전 단계의 변화를 인정하지 않는 것이 문제점이다.
2. 애자일 접근 방법론
폭포식 모델 보다는 변화를 잘 수용하고 위기 대응 관리를 잘 할 수 있는 유연한 접근 방식이다. 웹 사이트 개발 버전을 여러개로 나누어 한 단계를 완료할 때 마다 즉시 오픈하고, 모든 개발을 완료할 때 까지 이 과정을 반복한다.
(1) 수용 가능한 조건
- (가) 팀규모가 작아야 한다.
- (나) 서로의 물리적인 위치가 가까워야 한다.
- (다) 멤버 간 엄격한 역할 구분이 없어야 한다.
- (라) 각 단계가 끝날 때마다 과도한 문서 작업에 매달릴 필요가 없다.
- (마) 버전하나가 오픈되면 클라이언트의 요구를 수집하여 다음 버전에 적용한다.
(2) 긴밀한 협업을 유지하기 힘들기 때문에 실제 프로젝트에 적용하기 쉽지 않다.
3. 절충식 접근법
폭포식 접근 방식을 따르되 다른 팀으로 원활히 업무를 이전하기 위해 폭포식으로 진행하여 베타 오픈을 한 후 취합하여 애자일 방식 부분에 적용하여 정식 오픈 하는 방식이다.
WBS (Work Breakdown Structure)
프로젝트의 범위와 최종산출물을 세부요소로 분할한 계층적 구조로 프로젝트가 수행해야 하는 업무범위를 계층적 구조로 정의한 문서이다. WBS가 정의되어야 원가, 일정 등 다른 요소들도 정의할 수 있다.
1. 정의
- (1) WBS는 산출물에 기초하여 프로젝트 전체 범위를 조직하고 정의한 분할된 프로젝트 컴포넌트의 계층구조임
- (2) WBS는 프로젝트에 의해 성취되어야 할 작업을 구체화 한 프로젝트 상세범위기술서의 다른 표현임
- (3) WBS를 구성하는 요소들은 이해관계자들이 프로젝트의 최종 제품을 쉽게 이해할 수 있도록 도움을 줌
- (4) WBS의 가장 하위 컴포넌트를 대상으로 산정하고 스케줄링하며 진척관리를 함
- (5) 프로젝트가 관리를 가장 효과적으로 할 수 있도록 하는데 도움이 되는 작업관리 단위임
- (6) WBS는 팀의 프로젝트 역량과 작업자들의 작업관리 의지에 따라 상세화 수준이 좌우되고 조직의 원가관리 프로세스 수준에 영향을 받음
2. 중요성
- (1) 의사소통: 고객, 팀원간의 의사소통 수단
- (2) 가시화: 프로젝트 업무내역을 가시화, 관리 가능
- (3) R&R(Role & Responsibility): 프로젝트 팀원의 책임과 역할 명시
3. 목적
- (1) 프로젝트에서 수행할 업무 식별을 위한 도구
- (2) 프로젝트의 일정과 원가, 자원요구사항 식별을 위한 도구
- (3) 작업에 자원을 배정하기 위한 도구
- (4) 프로젝트 생산성 통제를 위한 도구
- (5) 고객, 프로젝트 팀 등 이해관계자와의 의사소통을 위한 도구
4. 예시
(1) 폭포수 생명 주기 기반의 WBS 예제
4. 구글 디자인 스프린트(Design Sprint)
디자인 스프린트란, 의사결정을 빠르고 신속하게 진행하는 Google의 디자인워크숍이다. 크고 새로운 기회들에 집중하기에 적합한 방식이다.이 방법은 월요일부터 금요일까지 5일간 이루어진다. 스프린트에 참가하는 팀원들은 먼저 프로젝트의 목표를 크게 그린 후, 목표의 문제점을 찾고(월요일), 해결책에 대해 브레인스토밍을 하고(화요일), 점진적인 결정을 내리고(수요일), 프로토타입을 만들고(목요일), 만든 프로토타입에 대한 유저들의 피드백을 받는다(금요일).
1. 월요일 : 목표를 크게 그리고 문제점 찾아보기
첫날에는 장기적인 목표를 세워야 한다. 그리고 그 목표를 달성하는 과정에서 발생하게 될 장애물들을 적어 보자. 문제점은 다양할 수 있다. 기술적으로 제품을 만들어내기 힘들거나 혹은 제품을 개발한다 해도 소비자층이 불확실할 수도 있다. 월요일 하루가 끝나갈 무렵에는 가장 중요한 주제를 파악하고, 가장 중요한 질문들의 리스트를 만들고, 앞으로 나아갈 방향을 설정하고, 일주일 동안 해결해야 하는 문제의 한 조각을 명료하게 확정 지어야 한다.
2. 화요일 : 주어진 과제에 대한 해결책 찾기
둘째 날은 문제에 대한 해결책을 마련하는 데 힘을 쏟아야 한다. 여기서 기억해야 하는 점은 모든 해결책이 ‘스케치’되어야 한다는 점이다. 메모를 하고 스케치 함으로써 중요한 디테일을 볼 수 있어야 한다. 이 단계에서 여러분은 소프트웨어 제품에 정확히 맞는 인터페이스를 찾을 수 있을지 걱정할 필요는 없다. 그저 제품의 작동 원리에만 집중하면 된다. 스프린트 과정에서 아무것도 안하는 ‘프리라이더’란 존재할 수 없다. 개개인은 브레인스토밍을 통해 해결책을 스스로 떠올려 보고, 모두가 자신이 생각해낸 해답을 소리 내어 공유해야 한다. 떄때로 해결책은 예상치 못한 곳에서 튀어 나온다. 웹 사이트를 구축할 때, 보통 사람들은 디자이너나 엔지니어의 입장에서 해결책을 궁리한다. 하지만 의외로 제일 좋은 아이디어는 매일 고객을 상대하는 CS 매니저에게서 나오기도 한다.
3. 수요일 : 중요한 결정 내리기
수요일 아침에는, 모든 스케치들을 벽에 붙이고 그 중에서 하나를 프로토타이핑 하기 위해 투표를 해야 한다. 투표에서 편견이 개입되지 않도록 각각의 스케치에는 구상한 사람의 이름을 가린다. 그 아이디어를 떠올린 사람에 대해서 고려하는 것이 아니라, 모든 것은 오로지 ‘새로운 아이디어’에 대한 것이어야 한다.
4. 목요일 : 프로토타입 만들기
목요일이 끝나갈 무렵, 완벽하진 않지만 얼추 그럴싸한 프로토타입을 만들어야 한다. 크냅은 프로토타입의 완성 정도가 ‘리뷰단에게 그럴듯한 반응을 불러일으킬 수 있을 정도’여야 한다고 말한다. 모든 제품이 다르기 때문에 프로토타입을 만드는 방법이 정해져 있을 수는 없다. 하지만 적어도 사용자들이 프로토타입을 접했을 때 ‘실제의 제품’처럼 느낄 수 있도록 만들어야 한다. 완벽함에 집착할 필요는 없다. 스프린트 방법의 요점은 ‘배움’에 있지, ‘제조’에 있는 것이 아니다. 그리고 여기서 가장 중요한 건 ‘시간 제한’이다. 프로토타입을 만드는 시간이 길어지게 되면, 그에 대한 아이디어와 완성도에만 집착하게 되게 때문이다. 신경 써야 할 것은 프로토타입에 대한 유저들의 반응이다.
5. 금요일 : 유저의 반응을 토대로 앞으로의 진행 방향 결정하기
금요일은 월요일에 정했던 핵심 질문에 대해 대답할 시간이다. 이를 위해서 여러분은 제품에 대해 편견 없이 소통하고 반응해줄 수 있는 5명의 소비자가 필요하다. 여러분이 그들로부터 얻어야 하는 것은 ‘피드백’이 아니라, ‘반응(reaction)’이다. 순간적으로 나오는 진심 어린 반응을 관찰해야 사람들이 실제로 대상을 대하는 방식을 알 수 있기 때문이다. 스프린트 팀에게 주어지는 역할은 소비자의 반응을 해석하고 목표를 적절히 수정하는 것이다. 스프린트 팀은 고객의 즉각적인 반응에서 힌트를 얻고, 이를 이용하여 제작 팀에게 제품을 만드는 방향을 지시하는 역할을 수행해야 한다. 여러분이 찾아야 하는 것은 소비자들이 보여주는 반응에서 보이는 패턴이다. 세 명 이상의 소비자에게서 비슷한 행동 패턴을 발견한다면, 그것이야말로 문제를 해결하는 핵심이 될 것이다.
- 1일차 : 이해 - 리서치와 경쟁사 리뷰, 전략 실험을 통해 디자인 문제를 탐구한다.
- 2일차 : 발산 - 가능한 많은 솔루션을 빠르게 만들어 낸다.
- 3일차 : 결정 - 가장 좋은 아이디어를 선택하여 유저스토리를 짜낸다.
- 4일차 : 시험제작 - 사용자에게 보여질 프로토타입을 만들어 낸다.
- 5일차 : 평가 - 프로토타입을 실제 사람들(회사 밖 사람들)에게 보여주어, 잘 된 것과 그렇지 못한 것을 배운다.
HyunZzang의 프로그래밍 공간 / 함께 공부해요!!
도움이 되셨다면 "좋아요❤️" 또는 "구독👍🏻" 부탁드립니다 :)
