Design Spectrum 후기
화성에서 온 디자이너 금성에서 온 개발자
개발자와 디자이너 간 협업하는 과정에서 의견 충돌이 일어나는 경우가 종종 있습니다.
하지만 이를 해결해 나가기는 생각만큼 쉽지 않습니다.
그런 고민이 있던 차에 좋은 행사가 있어서 참석했습니다.
https://nvite.com/DesignSpectrum/a0c1
https://www.facebook.com/sharedesignspectrum/
https://brunch.co.kr/@designspectrum/2
기술적인 발표 위주로 진행되었던 기존 개발 세미나와 달리 유쾌한 분위기 속에 행사가 진행되었습니다.
디자이너 분들이 많아서 인지는 모르겠지만 우선 기술적인 내용이 없었고,
그간 협업하며 느꼈던 답답하거나 이해 못할 상황과 그 후기들을 재미있게 발표해 주셨습니다.
개인적으로도 공감 가는 내용이 많아 재밌었습니다.
행사 말미에 디자이너 분들의 발표 내용은 저작권 이슈가 있기 때문에 공유가 어려울 수도 있다는 공지를 받았습니다.
그래서 개발자 & 디자이너 패널 토크 #1에서 인상 깊었던 내용들 위주로 정리하려 합니다.
1. 디자이너와 협업하면서 인상 깊었던 기억이 있나요?
재플린을 쓰자고 제안하신 그분과의 협업 경험이 인상 깊었습니다.
분명 디자이너가 시키는 대로 했는데 다르다고 하니까 답답했습니다.
그런 부분을 스케치를 도입하고 재플린을 통해 전달받으면서 어느 정도 해결이 되었습니다.
디자이너 분과 협업해서 론칭하는 과정에서 충돌이 발생하고 그 분과 앙금을 풀기 위해 티타임을 많이 가졌는데, 재플린을 쓰고 나서부터는 티 타임 하는 시간이 줄었습니다.
재플린을 쓰자고 제안하신 그분과의 협업 경험이 인상 깊었습니다.
"왜 이렇게 해야 돼요?" 가 아닌 "그래요? 이렇게 해봅시다"
3년 전쯤 머티리얼 디자인이 처음 나오고 이를 적용하려면 손봐야 할 게 많았습니다.
그런 부분을 디자이너 분들도 직접 가이드를 보면서 어떻게 적용할까 많이 고민하셨습니다.
저도 구글에서 제공하는 라이브러리 빠르게 적용하고 보여주며 서로 대화를 많이 했었습니다.
개발자가 느끼기에도 머티리얼 디자인이 다른 디자인에 비해서 규칙이 많은데 불평을 하기보다는,
"왜 이렇게 해야 돼요?" 가 아닌 "그래요? 이렇게 해봅시다" 하며 개발자의 의견도 잘 들어주셨고 결과적으로 좋은 앱을 만들 수 있었습니다.
이렇게 디자인 추가하려고 하는데 자기가 생각하기엔 개발적인 이슈가 있을 거 같다. 본인이 생각하기엔 어떤 게 좋고 편한 개발이냐?
재플린이 나오고 나서는 디자이너 분들과 충돌은 거의 없었습니다.
디자인이 추가되면 항상 제 자리로 오셔서 "이렇게 디자인 추가하려고 하는데 자기가 생각하기엔 개발적인 이슈가 있을 거 같다 본인이 생각하기엔 어떤 게 좋은 편한 개발이냐?"며 항상 물어보시는 분이 계셨습니다.
디자인이 나온 후에 개발을 하는 게 아니라 디자인과 개발이 같이 융합돼서 진행이 되는구나 느낌을 받았습니다.
그 디자이너 분과의 협업 경험이 가장 인상 깊고 따뜻하고 연애 같던 프로젝트로 남아 있습니다.
근거를 통해 주장하실 때는 이길 수 없었습니다.
개발자들은 종교적인 게 있습니다. 구글이나 애플에서 하라고 하면 믿고 따르는 편입니다.
구글의 안드로이드, 애플의 IOS 모두 공식적으로 인터페이스 가이드가 있습니다.
그 디자이너 분도 개발자가 가이드를 바탕으로 일을 진행하니 스스로 공부하셨고, 이를 근거로 말씀하시니 도저히 반박할 수 없었습니다.
이걸 참고해서 디자인하면 개발자를 다루기 편합니다.
2. 디자이너들이 이것만은 개선해 주었으면 하는 점이 있나요?
의견을 제시했을 때 반응이 중요하다고 생각합니다.
디자인이 바뀔 때 엄청난 차이가 느껴지냐 물으시면 솔직히 잘 안 느껴지는 경우도 있습니다.
하지만 피드백에 대한 디자이너분들의 온도 차이가 있습니다.
"아니 이걸 모르겠어요? 이 엄청난 차이를 모르겠어요?"
와 같은 냉담한 반응 때문에 어려운 경우가 발생하고 결국 나중에 요청이 들어오면 대충 해줄 때도 있습니다.
뭔가 리액션? 반응이 중요하다 생각합니다.
사전 고려가 있으면 좋을 거 같습니다.
안드로이드는 단말기마다 화면 사이즈가 다르니 예외 상황이 많이 발생합니다.
텍스트가 모두 나오지 못할 때... 처리하게 하는지, 중간에서 자르는지, 상세한 가이드가 안나지 않아 다시 여쭤볼 경우가 많았습니다.
이런 점들에 대한 사전 고려가 있으면 좋을 거 같습니다.
사전에 고려해서 개발자한테 주면 이 분 공부 열심히 하고 잘하시는 분이구나 하는 느낌을 받습니다.
QA전에 시간이 있을 때 미리 피드백을 주시면 더 잘 반영해 드릴 수 있습니다.
QA때 많이 질문을 하십니다.
사실 QA 전에 이렇게 나왔다 디자이너에게 미리 얘기했지만, 그땐 안 써보고 QA때 써보니 의도대로 안되었다.
다른 앱은 잘 되는데 여긴 안돼요 하면 좀 그렇습니다.
QA전에 시간이 있을 때, 미리 피드백을 주시면 더 잘 반영해 드릴 수 있습니다.
3. 개발자들이 이것만은 개선해 주었으면 하는 점이 있나요?
미적인 부분의 우리의 노고, 노력에 관심을 가져주시면 좋을 거 같습니다.
디자인 사이드에서는 개발을 공부하려는 움직임이 조금 있습니다.
그러나 어떤 개발자분들은 디자인에 관심이 1만큼도 없는 분이 있습니다.
서로 간 논의를 통해서 디자인을 공유해 드리면 자기 기준에 미적으로 좋으면 "정말 좋다. 우리 서비스에 좋을 거 같다"는 피드백을 주지만, 반대로 "전과 어떤 부분이 달라졌는지 모르겠다", 또는 노코멘트도 많습니다.
개발자 분들은 스펙 구현이 우선이기 때문에 이해하지만, 미적인 부분의 우리의 노고, 노력에 관심을 가져주시면 좋을 거 같습니다.
왜 안되는지 조금 설명을 해주면 좋을 거 같습니다.
안된다고 할 때, 어떤 개발자는 디자이 너니까 잘 모르겠지 하고 이유를 설명 안 해줍니다.
하지만 왜 안되는지 궁금할 때가 많습니다.
"넌 바보라 몰라" 그게 아니라 버전 때문인지 API 때문인지 조금 성의를 보여주고 설명해 주시면 좋을 거 같습니다.
저희의 노동이 헛되지 않도록 노력해주는 그런 마음을 가져 주시면 좋을 거 같습니다.
디자인만 했을 땐 개발자가 안 되는 게 많다고 할 때 "왜 안될까?" 싶은 마음이 들었지만, 사실 직접 코딩해보니까 안 되는 부분이 많습니다.
하지만 개발자분들에게 이거 해주세요 할 때 100퍼센트는 다 안 되는 게 아닙니다.
일정에 쫓기고 바쁘니까 안 되는 경우와 사고의 전환이 안 되는 경우가 있습니다.
약간 사고의 전환을 하면 쉽게 풀리는데 보통의 프로세스대로 하면 안 될 수 있습니다.
구현에 대해서 디자인도 노동을 많이 들이기 때문에 저희의 노동이 헛되지 않도록 노력해주는 그런 마음을 가져 주시면 좋을 거 같습니다.
서로 배우고 알려주는 태도가 중요합니다.
메테리얼 디자인을 천 번을 읽어야 어른이 된다고 생각합니다.
그걸 파고들면 다 의미나 이유가 있습니다.
하지만 처음엔 이해하기 어렵습니다.
디자이너 개발자 서로 새로운 기술과 디자인을 계속 배워야 합니다.
때문에 서로 배우고 알려주는 태도가 중요합니다.
4. 디자이너가 요구하는 것들 중 적용이 어렵다고 하는 경우가 있나요?
개발자도 인터렉션 넣어 더러워진 코드를 리펙토링 과정을 통해 정갈하게 만들고 싶어 합니다.
디자이너분들은 심미적인 부분을 중시합니다.
개발자도 인터렉션 넣어 더러워진 코드를 리펙토링 과정을 통해 정갈하게 만들고 싶어 합니다.
근데 그걸 해치고 시간도 없는데 요구하면 뒤를 안 닦고 나온 기분이 듭니다.
최대한 간결하고 이쁜 코드를 위해서는 거부감이 들게 됩니다.
일정과 코드의 아름다움 때문입니다.
디자이너분들도 레이어를 이쁘게 그룹핑하고 네이밍해야 psd를 전달할 수 있잖아요.
개발자들도 본인의 코드가 일기장 같은 거라서 더러운 코드를 남에게 보여주고 싶지 않습니다.
커스텀뷰는 필연적으로 코드가 어려워지고 그런 거에 대한 심적 거부감과
크게 중요하거나 미적인 게 아닌 게 일정이 오래 걸리는 경우 디자이너분께 말씀을 드립니다.
개발자로서 공감 가는 내용이 많았고 "코드가 일기장과 같다"는 표현이 참 와 닿았습니다.
한편으로는 디자이너 분들의 속마음을 많이 들을 수 있었습니다.
그분들의 오랜 노력이 개발자의 "안된다"는 말 한마디에 물거품 될 수 도 있구나 하는 생각이 들었네요.
