GDG(Google Developer Group Seoul)
‘디자이너와 개발자의 협력’ 세미나
7월 28일에 진행된 디자이너와 개발자의 협력 (Design X Development highlight) 세미나 늦은 후기
(https://www.meetup.com/ko-KR/GDG-Seoul/events/252856793/)
Google Developer Group Seoul에서 주최하는 세미나가 2018년 7월 28일에 있었습니다.
거의 2달 전 세미나인데, 이제야 후기를 남깁니다.
디자이너와 개발자 위주로 진행되는 프로그램이었지만 디자인 시스템 구축, 협력에 대해 흥미가 있어서 참석했고 결과적으로 만족스러운 세미나였습니다.
________________________________________
Session 01. 디자인 시스템 구축에 대한 생각과 고민
- 위메프 시니어 디자이너, 이상용님
1. 디자인 시스템이란
- Design System = UI Kit X Dev
- 표준화된 디자인 작업을 위한 상위 가이드라인
2. 디자인 시스템 구축을 위한 두 가지
1) Structure
- 디자이너 혼자 Structure 구축은 어려우므로 개발자와 함께 고민하여 만들어야 한다.
2) Organize
- 패턴을 보고 규칙을 만들어서 정리하고,
- 네이밍 룰, 레이어 이름 등 규칙을 정한다.
- 공통으로 합의된 규칙을 정한 후 작업해야 추후 정리에 소모되는 시간을 줄일 수 있고 커뮤니케이션 상 혼돈을 줄일 수 있다.
이 과정을 통해 일관성 있는 사용자 경험을 제공할 수 있고, 재사용성이 높아져서 유지보수도 쉬워짐
3. 디자인 시스템 구축에 따른 단점
1) 심미성보다 효율, 건설적인 사고만 우선시 될 수 있다.
but, 디자이너가 픽셀 단위로 수정하고 버튼의 위치를 고민하는 것 보다 더 가치있는 것을 고민해야 한다고 생각한다. 예를 들어 전체 브랜딩에 관련된 것이나 사용자 경험을 위한 디자인 전략 등. 이라고 상용님께서 말씀하셨다.
________________________________________
Session 02. 구글 머터리얼 디자인과 플러터
- 레진 엔터테인먼트, 조은실님
1. 플러터(Flutter.io)를 사용하여 메인 폰트나 컬러를 한 번에 바꿀 수 있다.
2. 분업으로 업무를 구분짓는 것이 아니라, 어떤 것을 필요로 하는지 궁금해하고 알아가는 것이 협업
________________________________________
Session 03. Git과 atomic으로 개선해본 협업 프로세스
- ab180, 원호택님 x 이찬희님
1. 문서로 전달된 디자인은 뛰어날지라도 완벽히 일치하여 구현은 어려움
- 상세설계로 완성 스펙으로 공유했는데도 직렬적으로 진행하는 문제
- 버전 관리 어려움
- 자잘한 수정이 필요할 때 애매한 커뮤니케이션
2. 그래서 어떤 방법을 선택했는가?
- Gitub에서 병렬적 작업 시작
- Git에서 개발자와 디자이너가 같은 화면을 보며 병렬적 작업이 가능해짐
- 커뮤니케이션 비용 절감
3. Atomic System
1) 스타일 가이드가 아닌 컴포넌트 구조적 가이드. 재활용과 일관성을 잘 이용하며, 확장 가능
2) Airbnb 에서는 design language system이라는 명칭으로 atomic system 이용중
3) AB180의 컴포넌트 ABC
- 재활용 : 어느 정도로 재활용 될 수 있는가 (확장, 마개조 등)
- 일관성 : 코드구조 스타일을 적용하는 법 등이 일관적인가
- 변화량 : 얼마나 많은 복잡도와 변화를 담을 수 있는가
But, 학습비용이 필요하고 스타일보다 효율, 건설적 사고가 우선적이 됨. 상대적으로 심미성이 낮아지는 단점이 있음
________________________________________
Session 04. 협업의 비밀
- 레이니스트, 황성현님
- TMI : 성현님은 작년 '이모;이상한 모임'에서 첨 뵀었는데 다시 뵙게되어 반가웠다. 요즘 협업에 대한 고민이 많은데 제일 와닿았던 세션이었다.
1. 소프트웨어 개발은 확실함보다 불확실함이 더 크다.
- 사용자의 요구사항은 언제나 불확실성이 크다.
- 제품을 만드는 일에는 팀 내부/외부의 변수가 몹시 많다.
- 즉, 스타트업에서의 완전한 분업은 불가능하다.
2. 소프트웨어 개발은 효율(=빨리 구현하고 빨리 배포하고)’만’을 목표로 삼지는 않는다
3. 완벽한 기능으로 가장 빠른 기간 안에 런칭해도, 사용자가 사용하지 않으면 무의미
4. 분업은 협업이 아니다.
- 사람이 많을 수록 빠르게 만들 수 있다고 생각을 하지만 그렇지 않음.
(워드 커닝햄, MinglingOfConcerns)
- 자연스럽게 팀이 된다는 생각이 협업을 막는다.
- 노력을 해야 협업이 가능하다는 생각을 해야 함
5. 협업 근육
- 시간이 지난다고 저절로 생기는 것이 아니다.
- 만드는 것도 어렵지만 노력한 만큼 생기지 않는다.
- 잘못된 습관은 해가 된다.
6. Stand-up meeting
- 업무 보고나 업무 공유 목적이 아니라 잠재적 리스크를 알 수 있는 자리가 되어야 함
- 말만 하는 것이 아니라 얼굴보고 비언어적 피드백 캐치 필요
- 업무 공유용이라면 메신저로 대체해도 되지만 비언어적 피드백은 놓치게 되고 협업 근육을 기를 수 없음
7. 예시로 들어준 기획자와 개발자의 대화
- 기획자 : ”세모난 동그라미를 만들어주세요”
- 개발자 : “안돼요” 가 아닌 “세모난 동그라미를 만드는데 100일이 걸리는데, 네모난 동그라미로 만들면 50일이 걸립니다. 목표가 동그라미를 만드는 것이라면 네모난 동그라미로 하는 것은 어떨까요?”
- 공통의 목표가 있다면 그 목표를 달성하기 위해 서로의 피드백이 필요함. 공통의 목표를 위한 일이라면 감정이 상할 일이 없음
8. 협업이 잘 이루어지고 있는 모델은 무엇일까?
1) 협업이 잘 이루어지지 않는 상황
- 피드백을 주고받다가 감정이 상했을 때 술 한 잔, 커피 한 잔이 해결책이 될 수 없다.
이것은 협업이 잘 되는 모델이 아니다. (그냥 감정 상한거라서)
- 개인적으로 친해지고나서 일을 진행하는 것은 조직역학적으로 회피적 관계임.
- 갈등을 회피해봤자 한계가 있음. 문제는 재발할 것이고, 본질적 문제 개선이 필요함.
- ‘갈등을 만들어도 조정이 안되고, 그냥 분란종자가 되면 어떡하지?’ ‘트러블메이커로 찍히면 어떡하지? 그냥 말하지 않아야겠다’ 라고 생각한다.
-> 심리적 안정감이 없는 상태
2) 그럼, 어떻게 해야하나?
- 더 자주, 더 잘 의견을 주고받는 것이 협업이 잘 되는 상태
- 술, 커피, 맛있는 음식과 대화시간이 필요한 것이 아니라 서로 의견을 공유 할 수 있는 시간과 건설적 피드백 필요
- 조직에 대한 심리적 안정감이 있어야 갈등을 만들고, 조정하는 것이 가능하다.
- ‘갈등이야말로 민주주의를 이끄는 동력이다’
- 공통 비전에 대해 팀원들이 모두 얼라인 되어있기 위해서는 리더의 역량 필요
________________________________________
개인적으로 기획자 X 디자이너 X 개발자의 협력이었으면 더 좋았겠다 라는 생각이 들었지만,
디자인 시스템과 협업에 대한 세션을 들은 후 내가 회사에서 할 수 있는 것들이 떠올랐습니다.
Stand-up meeting이 업무 공유 목적이 되지 않도록 어떻게 자연스럽게 시작할 수 있을까에 대해 고민하게 됐고요.
때마침 잠재적 리스크를 체크하지 못해서 이슈가 발생했고, 그걸 계기로 현재 자연스러운 Stand-up meeting을 진행하고 있습니다. (100% 만족할 정도는 아니지만 제가 더 공부를 해야할 것 같네요.)
좋은 자극이 되었던 세미나였고, 다음엔 기획자도 포함된 세미나가 있었으면 좋겠습니다 :)
제 뒷모습이 찍혔네요 ㅋㅋㅋ
'기획자입니다 > 세미나' 카테고리의 다른 글
| 나의 강점 찾기 (Feat. Tanagement) (0) | 2019.01.22 |
|---|---|
| 디자이너의 눈과 생각 빌리기 (0) | 2018.11.22 |
