수많은 서비스와 제품은 기획자, 디자이너, 개발자의 협업으로 만들어진다. 우리가 매일 마주하는 서비스들은 원활하고 완벽하게 작동되지만, 이것을 구축하는 과정은 상당히 험난했을 수 있다.
왜? 기획, 디자이너, 개발자는 때때로 사이가 좋지 않다.
모두 같은 목표를 향해 노력하지만, 그 목표를 바라보는 관점은 실제로 다를 수 있다. 디자이너들은 자신의 디자인이 원래 배치된 방식과 다르게 구현되는 것을 보고 화를 낼 수 있다. 개발자들은 디자이너들의 디자인 문제를 따지는 것에 불만을 품는다.
많은 갈등은 상대방에 대한 이해 부족에서 비롯되는데, 둘 간의 분열이 그런 경우라고 느껴졌다. 우뇌와 좌뇌 사이의 평화라는 이름으로 생각을 정리한다.
“기획/디자인: 우리는 어려운 일을 만드는 것이 아니다.”
우리는 좋은 일을 하려고 노력하고 있다. 어려운 사람이 되려고 노력하지 않는다. 일부 개발자들 사이에서 유지 관리 수준이 높다는 얘기를 듣고 있고 우리가 기능보다 형태를 선호한다고 생각하는데, 이는 전혀 사실이 아니다. 기능을 최대한 활용할 수 있도록 기능에 가장 적합한 형태를 고안하려고 노력하고 있다.
과거와는 다르게 사용자 경험(UX)에 대한 역할을 맡고 있다. 해당 요구사항에 맞게 기획/디자인 하기전에 사용자에게 무엇을 제공해야 하는지 이해하는 것이 중요하다. 때때로 미려한 그래픽을 추가하려고 시도하지만, 이는 단지 사용자의 경험이 즐거운 경험이 되길 원하기 때문이다.
”개발: 우리는 어려운 사람이 되려고 노력하는 것이 아니다.”
코드를 작성할 때 프로젝트의 완성은 우리가 생각하는 것의 일부일 뿐이다. 앱은 시간이 지남에 따라 변경되며, 우리는 이런 변경이 쉽게 이루어질 수 있도록 노력하고 있다. 자동화된 테스트를 할 수 있는 코드도 필요하고, 구성 요소 등 우리가 당신들로부터 받은 작업 결과물에 대한 변경을 요청하는 것은 모두의 미래를 위해 테스트 가능하고 유연하게 유지하려는 목적이다.
걱정하지 않았으면 좋겠다. 유연성을 구축하는 것은 비용이 많이 들 수 있고 미래를 위한 과잉 구축을 의미할 수 있기 때문에 무한한 유연성을 요구하진 않는다. 우리는 “YAGNI”를 피하려고 노력한다.
“기획/디자인: 우리가 이해하도록 도와달라”
우리는 규칙을 배울 수 있고, 규칙을 이해하도록 도와주면 된다. 우리가 개발자들이 이해하지 못하는 언어로 때때로 말하듯이, 개발자도 우리가 이해하지 못하는 언어로 우리에게 말한다. 서로 이해하고 나면 가장 큰 혜택을 받는 사람은 사용자이다. 모두가 승리한다.
우리는 규칙을 따르지 않고 “고정관념에서 벗어나서 생각”하도록 교육을 받았다. 이것이 개발자의 삶을 어렵게 만들어야 한다는 의미는 아니다. 우리가 규칙을 이해하면 기능을 더 어렵게 만들지 않고도 한계를 뛰어넘어 규칙에서 벗어날 수 있다. 올바르게 동작되면 그래픽 기능도 강화할 수 있다.
“개발: 데스크탑에서 작동하는 것이 웹에서는 작동하지 않을 수 있다.”
윈도우 환경에서는 대소문자 파일 이름 구별이 중요하지 않을 수 있지만, 리눅스에서는 대소문자를 구별한다. 가능하면 파일 이름을 모두 소문자로 사용하는 것을 선호하며 하이픈으로 단어를 구분한다.
브라우저에서 이미지를 볼 때 큰 파일의 로드 시간이 눈에 띄지 않을 수도 있지만, 배경으로 사용하는 페이지 크기가 메가바이트라면 천천히 로드 되어야 한다. 성능을 계산하는 브라우저 플러그인이 많이 있으니 이를 사용했으면 좋겠다.
결론
서로 자기 입장만 얘기하면 협업이 어려워 질 수 있다. 본질적으로는 함께 협업을 해야 좋은 결과가 나온다. 그들은 동전의 양면이다. 각각 작동하지만 동일한 제품의 서로 다른 결과물에 초점을 맞추고 있다.
사용자 원하는 요구 사항을 충족하려면 두 가지 기술이 모두 필요하다. 기획/디자인, 개발은 동시에 작업하지 않고 순차로 작업한다. 예를 들어 기획/디자인은 초기에 개발자와 상담해야 한다. 연관된 제약 조건을 아는 것외에 실제로 구현될 수 있도록 보장되는지 확인이 되어야 한다.
하지만 실제로는 서로 다른 전문가들이 오해를 하는 경우가 많다. 서로의 지식을 이해 못하는 것은 오히려 자연스러운 것이다. 우리가 실천해야 할 것은 서로를 이해하는 법을 배워야 한다.
서로 사이 좋게 지내려면 어떻게 해야 할까? 첫째, 미팅에 참석해야 한다. 기획/디자이너 미팅에 개발자가 초대되어 브레인스토밍 세션 중에 합의를 해야 한다. 회의에 개발자를 초대하면 모든 당사자가 같은 환경에서 이해할 수 있게 된다. 너무 늦기전에 다툼을 방지하기 위해 업무를 시작하기 전에 서로 주의할 사항에 대해서 논의할 수 있어야 한다. 이 프로세스를 통해 잘못된 결과에 대해 소요되는 시간도 단축될 수 있다.
둘째, 피드백으로 소통해야 한다. 일반적인 충돌은 개발 중에 일부 사항이 누락되어 발생한다. 개발자는 이를 사소하게 여기고 삭제하거나 변경할 수도 있다. 따라서 기획/디자인과 개발 프로세스 사이에 피드백을 공유하는 것이 중요하며 권장해야 한다.
셋째, 팀으로 협력해야 한다. 개발자와 기획/디자이너는 엄연히 다른 직업이지만, 서로 다른 직업으로만 생각한다면 둘 사이의 간극을 메우는 데 도움이 되지 않는다. 서로를 하나의 팀으로 보려고 노력해야 한다. 누구나 기한 내에 좋은 품질로 제품을 완성해 출시하고 싶어하는데 그러기 위해서는 협력을 해야 한다. 일반적으로 상대방을 이해할 수 없을 때는 타협이 어렵다. 그러니 미워하기보다는 이야기하고 협상을 해야 한다. 궁극적으로 더 나은 팀이 되기 위해 한 단계 더 나아가는 것이다.
넷째, 서로 협업하여 작업할 수 있도록 만들어진 다양한 도구가 있다. 이러한 도구들은 개발자와 디자이너가 동일한 정보를 공유할 수 있도록 도와준다. 즉, 공동 작업보다 실질적이고 효과적으로 작동할 수 있도록 해준다. 예를 들어, Storybook은 UI 구성 요소와 페이지를 별도로 구축하기 위한 오픈 소스 도구이다. UI 개발, 테스트 및 문서화를 간소화한다. 또한 개발을 표준화하고, 코드 중복을 줄이고, 팀 간 협업을 개선하고, 확장성을 촉진 할 수 있는 기회를 제공한다.
기획/디자인, 개발은 서로에게서 배울 수 있는 것이 많다. 어떤 역할을 하더라도 프로젝트 측면에서 고민해야 한다. 어느쪽도 서로에게 고통을 주려고 하지 않는다. 서로 아는 것과 경험, 관점이 다르기 때문이다.
불일치를 피하는 가장 좋은 방법은 프로세스 초기에 자주 소통하는 것이다. 가능한 한 빨리 개발자를 참여시켜야 한다. 이렇게 해야 핸드오프 단계가 시작되기 훨씬 전에 잠재적인 문제를 식별하고 해결 할 수 있다.
지식을 공유하는 것도 중요하다. 코딩을 배울 필요는 없지만, 개발자의 작업 방식과 그들이 직면한 과제를 이해하는 데 시간을 할애하는 것은 가치가 있다.
기획/디자인 측면에서 사용자가 필요로 하는 것, 경험하는 것 이상의 부분에 집중할 수 있다고 생각한다. 물론 이것은 매우 중요하다. 하지만 요구 사항과 프로젝트가 전반적으로 얼마나 효과적으로 개발될 수 있는지 집중해야 한다. 팀에 효과적인 의사소통, 효율성 및 일관성이 부족한 경우에는 사용자 경험에 영향을 미칠 수 있기 때문이다.
결국 우리 모두는 훌륭한 결과를 만들고 싶어한다. 하지만 그러기 위해서는 이해와 타협을 바탕으로 한 일관된 팀워크가 뒷받침되어야 한다. 좋은 결과를 만드는 것을 잊지 말아야 한다.
