[2012 pxd talks 11] 성공하는 제품 디자인을 위한 비밀 무기 (Secret weapon for successful product design)
2012. 10. 18. 08:50ㆍpxd talks
지난 10월 11일에는 nhn에서 근무하시는 우상훈님께서 '성공하는 제품 디자인을 위한 비밀 무기'라는 주제로 강의를 해주셨습니다.
약 15년 간 프로그램 개발과 UI디자인을 모두 경험해보신 강사님의 이력답게 디자이너와 개발자가 어떻게 상생할 수 있는지와 디자이너의 전문성을 기르는 원칙에 대해서 깊이 있는 내용을 들을 수 있었습니다.
강의는 다음과 같은 순서로 진행되었습니다.
1. Understanding
인터넷 유머 중에 디자이너가 엄청 혁신적인 제품의 컨셉을 보여주자 엔지니어가 '와 멋진데? 그거 원리가 뭐야?' 라고 물어보니, 디자이너가 '그건 니가 생각해내야지' 라고 말하는 유머가 있습니다. 엔지니어가 실제로 작동하는 제품을 구현해내는 고충을 고려하지 않는 디자이너의 이기적인 모습을 꼬집는 풍자유머인데요.
이 글을 읽고 있는 디자이너 분들은 개발자를 얼마나 이해하고 있다고 생각하시나요?
개발자들이 매번 이렇게 바꾸면 안된다고, 스펙이 불충분하니까 좀 명확하게 해달라고 할 때마다 '왜 저렇게 안된다는 게 많고, 좀 알아서 구현하지 그렇게 사소한 것 까지 정해줘야 하나?' 하는 생각하고 계시진 않으신지요.
이러한 차이가 생기는 이유로 강사님께서는 디자이너와 개발자의 제품 개발에 대한 마인드셋이 다르기 때문이라고 지적하셨습니다.
about 제품 개발
위와 같이 개발자는 기능 하나에도 엄청나게 많은 점을 고려해야 하기 때문에, 디자이너에게 작은 변경으로 보이는 것이 개발자에게는 쉽지 않다는 것이죠.
우상훈님은 이러한 개발자의 입장을 이해하는 견지에서 더 나아가, 개발자와 함께 발생 가능한 변수를 최소화하는 노력을 기울이고, 내가 틀릴 수 있음을 인정하면서도 근거있는 디자인을 제시함으로써 상호간의 신뢰를 구축하는 것이 매우 중요하다고 강조하셨습니다.
2. Turn the tables
제품개발 과정에서 인터랙션 디자이너는 어떠한 역할을 해야할까요?
결론적으로 우상훈님은 개발자가 의지할 수 있는 전문가이자, 다양한 직군들 사이에서의 중간자 역할을 해야 한다고 하셨습니다.
개발업무는 제품개발 과정에서 가장 마지막에 위치하기 때문에 일정이 매우 촉박하고, 개발자는 기능 하나에도 많은 것을 고려해야 하기 때문에 여기 저기서 들려오는 많은 의견들을 다 수용하기가 매우 어렵다고 합니다.
따라서 제품개발 과정의 앞 단계의 일을 수행하는 인터랙션 디자이너가 다양한 곳에서 오는 의견을 종합하여 개발자에게 필요한 것들을 전달하고, 개발자는 오로지 개발일에만 전념할 수 있도록 도와주는 역할을 해야 한다고 하셨습니다. 그리고 개발자가 하지 않아도 될 것을 확실히 정하는 것 또한 인터랙션 디자이너의 역할이라고 하셨고요.
이러한 역할을 잘 수행하기 위해서 의사소통 능력을 매우 강조하셨습니다.
3. Storyboard
인터랙션 디자이너는 제품의 사용자를 바라보고 설계해야 하지만, 그 설계서(Storyboard)를 해석하고 제품으로 만들어 내는 것은 결국 개발자입니다.
그렇기 때문에 인터랙션 디자이너는 스토리보드의 최종사용자인 개발자의 눈높이에 맞춰서 이해하기 쉬운 스토리보드를 써야한다고 하셨습니다.
특히 간결한 문장으로 글을 써야 하는 점을 강조하셨는데요, 이해를 돕기 위해 작업시간 추정의 심리에 관한 실험결과를 예를 들어 설명해주셨습니다.
실험 참가자들은 실제로는 똑같은 스펙이지만 정보가 더 많은 것 처럼 보이면 더 많은 작업시간이 걸릴 것이라고 추정하는 경향이 있다고 합니다. 심지어는 여백을 많이 주고 폰트 크기만 키웠을 뿐인데도 더 많은 작업시간이 걸릴 것으로 추정했다고 하네요.
이러한 심리적인 이유 때문에라도 명확하면서도 간결하게 스토리보드를 써야하겠습니다.
그리고 개발자의 눈높이에 맞출 수 있는 방법은 빠른 방법은 바로 개발을 직접 해보는 것이라고 하셨습니다.
디자이너가 쉽게 배워볼 수 있는 개발언어로 Javascript와 jQuery를 알려주셨고, 이를 통해 프로토타이핑 능력을 기를 것을 권장하셨습니다.
이렇게 개발자를 이해하면 기능을 빼는 등의 적극적인 협상도 가능한 장점이 있다고 합니다.
무엇보다 개발을 직접 해보는 것은 궁극적으로 UI를 거쳐서 사용자가 만나게 되는 시스템 그 자체를 이해할 수 있기 때문에, 시스템과 사람을 연결하는 임무를 가진 인터랙션 디자이너로서 반드시 필요한 일이라고 하셨습니다.
글을 마치며…
강의 전체에 흐르고 있는 메시지는 '이해 Understanding' 였습니다.
제품개발은 절대 디자이너 혼자서는 할 수 없는 것이기에 결국 성공적인 제품을 디자인하기 위해서는 일반 사용자를 이해 하는 것 뿐 아니라 제품을 함께 만들어 나가는 '개발자에 대한 이해'가 필수불가결한 것이라는 것, 바로 그것이 성공의 비밀무기라는 것을 배울 수 있는 시간이었습니다.
약 15년 간 프로그램 개발과 UI디자인을 모두 경험해보신 강사님의 이력답게 디자이너와 개발자가 어떻게 상생할 수 있는지와 디자이너의 전문성을 기르는 원칙에 대해서 깊이 있는 내용을 들을 수 있었습니다.
강의는 다음과 같은 순서로 진행되었습니다.
1. Understanding - 개발자를 이해하기
2. Turn the tables - 프로젝트에서 인터랙션 디자이너의 역할
3. Storyboard - 의사소통의 도구
2. Turn the tables - 프로젝트에서 인터랙션 디자이너의 역할
3. Storyboard - 의사소통의 도구
1. Understanding
인터넷 유머 중에 디자이너가 엄청 혁신적인 제품의 컨셉을 보여주자 엔지니어가 '와 멋진데? 그거 원리가 뭐야?' 라고 물어보니, 디자이너가 '그건 니가 생각해내야지' 라고 말하는 유머가 있습니다. 엔지니어가 실제로 작동하는 제품을 구현해내는 고충을 고려하지 않는 디자이너의 이기적인 모습을 꼬집는 풍자유머인데요.
이 글을 읽고 있는 디자이너 분들은 개발자를 얼마나 이해하고 있다고 생각하시나요?
개발자들이 매번 이렇게 바꾸면 안된다고, 스펙이 불충분하니까 좀 명확하게 해달라고 할 때마다 '왜 저렇게 안된다는 게 많고, 좀 알아서 구현하지 그렇게 사소한 것 까지 정해줘야 하나?' 하는 생각하고 계시진 않으신지요.
이러한 차이가 생기는 이유로 강사님께서는 디자이너와 개발자의 제품 개발에 대한 마인드셋이 다르기 때문이라고 지적하셨습니다.
about 제품 개발
디자이너의 마인드셋 = 인터랙션 디자인 + 개발
개발자의 마인드셋 = 인터랙션 디자인 + 개발 + 퍼포먼스 + 유지보수 + 트러블 + 테스트 + 변경 후 부작용 + …
개발자의 마인드셋 = 인터랙션 디자인 + 개발 + 퍼포먼스 + 유지보수 + 트러블 + 테스트 + 변경 후 부작용 + …
위와 같이 개발자는 기능 하나에도 엄청나게 많은 점을 고려해야 하기 때문에, 디자이너에게 작은 변경으로 보이는 것이 개발자에게는 쉽지 않다는 것이죠.
우상훈님은 이러한 개발자의 입장을 이해하는 견지에서 더 나아가, 개발자와 함께 발생 가능한 변수를 최소화하는 노력을 기울이고, 내가 틀릴 수 있음을 인정하면서도 근거있는 디자인을 제시함으로써 상호간의 신뢰를 구축하는 것이 매우 중요하다고 강조하셨습니다.
2. Turn the tables
제품개발 과정에서 인터랙션 디자이너는 어떠한 역할을 해야할까요?
결론적으로 우상훈님은 개발자가 의지할 수 있는 전문가이자, 다양한 직군들 사이에서의 중간자 역할을 해야 한다고 하셨습니다.
개발업무는 제품개발 과정에서 가장 마지막에 위치하기 때문에 일정이 매우 촉박하고, 개발자는 기능 하나에도 많은 것을 고려해야 하기 때문에 여기 저기서 들려오는 많은 의견들을 다 수용하기가 매우 어렵다고 합니다.
따라서 제품개발 과정의 앞 단계의 일을 수행하는 인터랙션 디자이너가 다양한 곳에서 오는 의견을 종합하여 개발자에게 필요한 것들을 전달하고, 개발자는 오로지 개발일에만 전념할 수 있도록 도와주는 역할을 해야 한다고 하셨습니다. 그리고 개발자가 하지 않아도 될 것을 확실히 정하는 것 또한 인터랙션 디자이너의 역할이라고 하셨고요.
이러한 역할을 잘 수행하기 위해서 의사소통 능력을 매우 강조하셨습니다.
3. Storyboard
인터랙션 디자이너는 제품의 사용자를 바라보고 설계해야 하지만, 그 설계서(Storyboard)를 해석하고 제품으로 만들어 내는 것은 결국 개발자입니다.
그렇기 때문에 인터랙션 디자이너는 스토리보드의 최종사용자인 개발자의 눈높이에 맞춰서 이해하기 쉬운 스토리보드를 써야한다고 하셨습니다.
특히 간결한 문장으로 글을 써야 하는 점을 강조하셨는데요, 이해를 돕기 위해 작업시간 추정의 심리에 관한 실험결과를 예를 들어 설명해주셨습니다.
실험 참가자들은 실제로는 똑같은 스펙이지만 정보가 더 많은 것 처럼 보이면 더 많은 작업시간이 걸릴 것이라고 추정하는 경향이 있다고 합니다. 심지어는 여백을 많이 주고 폰트 크기만 키웠을 뿐인데도 더 많은 작업시간이 걸릴 것으로 추정했다고 하네요.
이러한 심리적인 이유 때문에라도 명확하면서도 간결하게 스토리보드를 써야하겠습니다.
그리고 개발자의 눈높이에 맞출 수 있는 방법은 빠른 방법은 바로 개발을 직접 해보는 것이라고 하셨습니다.
디자이너가 쉽게 배워볼 수 있는 개발언어로 Javascript와 jQuery를 알려주셨고, 이를 통해 프로토타이핑 능력을 기를 것을 권장하셨습니다.
이렇게 개발자를 이해하면 기능을 빼는 등의 적극적인 협상도 가능한 장점이 있다고 합니다.
무엇보다 개발을 직접 해보는 것은 궁극적으로 UI를 거쳐서 사용자가 만나게 되는 시스템 그 자체를 이해할 수 있기 때문에, 시스템과 사람을 연결하는 임무를 가진 인터랙션 디자이너로서 반드시 필요한 일이라고 하셨습니다.
글을 마치며…
강의 전체에 흐르고 있는 메시지는 '이해 Understanding' 였습니다.
제품개발은 절대 디자이너 혼자서는 할 수 없는 것이기에 결국 성공적인 제품을 디자인하기 위해서는 일반 사용자를 이해 하는 것 뿐 아니라 제품을 함께 만들어 나가는 '개발자에 대한 이해'가 필수불가결한 것이라는 것, 바로 그것이 성공의 비밀무기라는 것을 배울 수 있는 시간이었습니다.
[참고 - 2012 pxd talks - Talk, Workshop & Coaching]
- 2012/12/28[2012 pxd talks 14] 적정기술의 의미와 역사 by
- 2012/12/03[2012 pxd talks 13] Service eXperience Design by
- 2012/11/16[2012 pxd talks 12] 현실과 상상의 경계 :: 이수지 작가의 그림책 이야기(3) by
- 2012/10/18[2012 pxd talks 11] 성공하는 제품디자인을 위한 비밀무기 (Secret weapon for successful product design) by
- 2012/09/27[2012 pxd talks 10] 디자인 씽킹과 앙터프러너십 : 숨겨진 니즈와 지속가능한 솔루션을 찾는 통합 모델과 사례 by
- 2012/09/03[2012 pxd talks 09] Mindstorming by
- 2012/07/11[2012 pxd talks 08] 효과적으로 전문가 인터뷰하기 by
- 2012/06/23[2012 pxd talks 07] Extreme Prototyping : Being Resourceful in Prototyping by
- 2012/05/14[2012 pxd talks 06] 소셜미디어 진화 방향과 사회적 이슈 by
- 2012/04/02[2012 pxd talks 05] SMI 아이트래커 활용 방법 및 사례 by
- 2012/03/29[2012 pxd talks 04] UI 스터디 워크샵 후기 - 컨텍스추얼 인터뷰 by
- 2012/03/15[2012 pxd talks 03] 부엉이 쪽지 기획/개발/운영 by
- 2012/02/15[2012 pxd talks 02] 서비스 디자인 워크샵 후기 (2) by
- 2012/02/15[2012 pxd talks 01] 정보 시각화(Information Visualization) by