모든 팀이 설계와 개발 통합의 완벽하고 조화로운 균형을 유지하는 것은 아닙니다(저에게는 어려운 팀이 꽤 있었습니다). 어떤 이유에서든 개발자와 디자이너는 종종 불필요하게 서로 적대감 을 나타냅니다. 이러한 통찰력은 이야기의 다른 면을 드러냅니다. 나는 이 두 팀이 같은 목표를 가지고 있고 그 결과에 도달하기 위해 서로를 지원할 자격이 있다고 생각합니다. 나는 최근에 내가 UX 연구에서 그들의 요구에 대해 소프트웨어 엔지니어와의 인터뷰 에서 배운 것에 대해 썼습니다 . 같은 인터뷰에서 엔지니어의 피드백 관리에 대한 몇 가지 통찰력을 발견했습니다. 디자이너와 개발자는 공통점이 많습니다. 우리는 소프트웨어 개발 분야에서 가장 창의적인 두 그룹입니다. 우리 둘 다 끊임없이 새로운 것을 만들고 있습니다. 그런 식으로 두 팀은 키울 가치가 있는 중요한 파트너십을 구성합니다. 귀하의 팀을 위한 실행 가능한 테이크아웃에 대한 저의 인터뷰 하이라이트를 읽으십시오. 디자인 및 개발 파트너십 디자이너는 피드백을 기대해야 합니다. 피드백은 단일하지 않고 일정해야 합니다. 디자이너가 개발자로부터 피드백을 받아야 하는 이유 피드백을 통해 신뢰 구축 피드백은 충성도를 구축할 수 있는 기회입니다. 기술과 시간을 존중하라 틀려도 괜찮아 마무리 디자인 및 개발 파트너십 디자이너는 다양한 입력과 이해 관계자의 피드백을 저글링해야 합니다. 핵심 이해 관계자 중 하나는 개발 팀 입니다 . 실제로 디자인을 현실로 만들 재능 있는 사람들입니다. 나는 몇몇 개발자들에게 어떤 상황이 디자인 과정에서 마찰을 일으키는지 물었습니다. 그들은 언제 디자인을 지지해야 한다고 생각합니까? 응답은 광범위했지만 공통 주제 아래 통일되었습니다. 구경하다: "플랫폼별 디자인이 아닌 경우"(특히 Android 및 iOS 참조) 엔지니어링 노력(구축 시간)이 "있는 그대로의 설계를 얻는 이점보다 중요"할 때 설계가 시스템 아키텍처에 피해를 줄 수 있는 경우 디자인이 "개발 시간 구덩이"일 때 개발자가 결정을 "무효화"하는 역사적 지식이나 데이터를 가지고 있는 경우(개발자는 UX 연구를 이해할 자격이 있기 때문에 공유한 것일 수도 있습니다! ) 훌륭한 엔지니어는 자신이 구축한 솔루션의 품질과 무결성을 중요하게 생각합니다. 그들은 디자이너가 우리 자신의 시스템과 프로세스에 대해 생각할 때 하는 것처럼 기술 의 장점을 찾습니다. 디자이너는 피드백을 기대해야 합니다. 디자인 작업이 팀(또는 회사 전체)에 미치는 영향에 대해 잠시 생각해 보십시오. 설계는 엔지니어가 앞으로 며칠, 몇 주 또는 몇 달 동안 시간을 ​​보내는 방식을 결정합니다. 해당 솔루션이 고객에게 도달하는 방식이 비즈니스 또는 조직의 성공을 좌우합니다. 그것은 큰 책임입니다! 아이디어 구축 을 담당하는 사람과 팀 이 아이디어를 계획하고 실행하는 방법에 대한 피드백을 받는 것은 당연합니다. 한 엔지니어가 설명했듯이 제안을 제공할 때 "더 나은 솔루션이 아니라 동일한 결과에 도달하지만 엔지니어링 팀의 노력의 절반만 받는 방법"일 수 있습니다. 최근의 예 A/B 테스트 실험이 마감일에 도달할 수 있는 빠른 아이디어를 스케치했습니다. 내가 그 아이디어를 작업할 개발자에게 보냈을 때 그는 약간의 주저함을 표현하기 위해 저에게 전화를 걸었습니다. 그는 디자인이 A/B 테스트에 적합하지 않은 이유에 대해 훌륭한 요점을 제시했습니다. 그는 내가 서두르면서 간과 한 몇 가지 세부 사항을 지적하기까지했습니다. 그는 솔직히 더 나은 대안을 제안했습니다. 나는 그가 편안하게 뒤로 물러서고 실패한 테스트를 피할 수 있도록 도와줘서 기쁩니다. 피드백은 단일하지 않고 일정해야 합니다. 최근 Jess Eddy의 UX Chat 에서 그녀는 개발자 관계를 "인수"로 생각하지 않는다고 언급했습니다. 대신 그녀는 그것을 "지속적인 의사 소통의 흐름"으로 간주합니다. 디자이너와 엔지니어의 참여는 시작 과 끝 이 아니라 프로젝트가 진행됨에 따라 변동하고 역할을 변경합니다. 이용 가능 여부에 대한 참고 사항 이것이 디자이너가 모든 이메일이나 DM에 즉시 응답해야 한다는 압박감을 느껴야 한다는 의미는 아니라고 생각합니다. 디자이너가 항상 "대기" 상태일 필요는 없습니다. 나는 그것이 디자이너들이 가능한 한 빨리, 그리고 가능한 한 빨리 그 문을 열어야 한다는 것을 의미한다고 생각합니다. 프로젝트가 추상적에서 구체적으로 전환될 때 팀의 다양한 접점에 대해 생각해 보십시오. 다른 사람에게 알리고 피드백을 요청할 수 있는 곳은 어디입니까? 몇 가지 예: 회사 또는 팀 전략 변경 후 로드맵에 새로운 계획이 추가된 경우 프로젝트 킥오프에서 연구보고 후 UI 탐색 중 A/B 테스트 결과 후 영업 피드백을 받을 때 개발자가 이러한 접점에 관심을 갖는 이유를 알고 싶다면 UX 연구에서 개발자가 필요로 하는 것에 대한 제 이전 게시물을 읽어 보세요. 디자이너가 개발자로부터 피드백을 받아야 하는 이유 이 엔지니어보다 더 명확할 수 없습니다. "디자인 결정에 대한 전체 컨텍스트, 데이터 및 연구를 공유할 수 있다면 개발자가 이해하고 일이 이루어지도록 도울 것입니다." 개발자는 강력한 동맹입니다. 내가 함께 일한 가장 숙련된 개발자 중 일부는 또한 자신의 작업과 마감일을 맹렬히 방어했습니다. 신뢰 관계를 구축하면 해당 개발자도 귀하가 관심을 갖고 있는 항목을 방어할 수 있습니다. 접근성, 디자인 시스템 무결성, 구성 요소 아키텍처 및 사용성을 위해 노력하는 개발 팀을 상상해 보십시오. 그 꿈은 상호 존중을 통해서만 실현됩니다. 한 엔지니어는 설계를 뒤로 미루는 것에 대해 질문 을 받았을 때 "나는 주어진 솔루션으로 앞으로 나아가는 경향이 있습니다. 잘 생각하고 무언가를 만들고, 거기서 배우고, 반복하는 것이 일반적으로 가장 좋다는 가정하에"라고 말했습니다. 제품을 만드는 방법입니다." 당신은 그들이 "그것이 잘 고려되었다"는 것을 알아차렸습니까? 쉬운 성과가 아니라는 것. 어떻게 그 신뢰를 얻습니까? 피드백을 통해 신뢰 구축 팀에 대한 신뢰를 구축하는 가장 쉽고 빠른 방법 중 하나는 피드백을 초대한 다음 즉시 조치를 취하는 것입니다. 피드백은 충성도를 구축할 수 있는 기회입니다. 일부 엔지니어는 들어오는 피드백을 많이 처리할 수 있는 디자이너에게 훌륭한 조언을 제공했습니다. "개발자들에게 실제로 피드백을 듣고 있다는 것을 보여주고 필요한 경우 일대일로 만나 더 많은 이야기를 나누세요." 일부 디자이너는 그것을 읽고 매우 붐비는 회의 일정의 공포를 느낄 수 있습니다. 회의가 필요한 시기를 결정하는 것은 귀하에게 달려 있습니다. 회의 시간은 5분 이내라는 것을 잊지 마십시오. 또 다른 엔지니어는 "디자이너가 이 문제를 해결할 향후 계획이 있으면 팀에 알려주십시오."라는 유용한 정보를 제공했습니다. 이러한 응답은 모두 공통적이고 중요한 진실을 공유합니다. 피드백을 잘 처리한다는 것은 피드백 을 어디로 보낼지 아는 것을 의미합니다 . 다음은 피드백을 처리할 때 사용할 수 있는 몇 가지 응답입니다. 나는 그것을 고려하지 않았습니다 . 그것에 대해 다시 연락해 도 될까요? (그럼 실제로 해봐) 나는 당신이 어디에서 왔는지 볼 수 있습니다. 그것이 우리가 해결할 수 있을지 확신할 수 없지만, 이 회의가 끝난 후에 여러분과 함께 그 문제를 해결하고 싶습니다. 올려주셔서 감사합니다. 지금 당장은 (로드맵/타이밍/연구/기타)로 인해 그렇게 할 계획이 없지만 관심이 있다면 이에 대해 더 이야기할 수 있어 기쁩니다. 피드백에 응답하는 것 자체가 하나의 예술 형식입니다. 다음은 귀하가 경청하고 피드백이 합리적이며 응답하기 위해 기꺼이 일하고 있음을 보여주는 몇 가지 예입니다. 기술과 시간을 존중하라 디자이너들은 종종 테이블에 앉을 자리를 움켜쥐고 디자인에 대한 존중을 요구합니다. 개발은 어떻습니까? 디자인과 개발은 서로의 시간 약속에 많은 영향을 미치기 때문에 상호 존중이 중요합니다. 일부 엔지니어는 이에 대해 함께 작업하기를 원합니다. "개발 시간이 걱정된다면 팀과 함께 사용 가능한 다른 옵션이 무엇인지 알아내십시오." 개발 시간에 대한 응답은 누군가가 반대하는 것이 아니라 팀의 이익에 관한 것임을 기억하십시오. 밀려나는 느낌이 든다면 그것이 어디서 오는지 찾아보십시오. 개발 프로세스를 존중하는 또 다른 방법은 올바른 규칙(예: 플랫폼별 패턴)을 이해하고 적절하게 활용하는 것입니다. "지금까지 내가 반발하는 가장 큰 이유는 디자인이 플랫폼에 국한되지 않을 때입니다." 팀이 관례에서 벗어나 통일된 선택을 하는 것은 한 가지입니다. 엔지니어가 예상치 못한 설계 선택에 놀라는 것은 또 다른 문제입니다. 관례를 무시하는 것이 올바른 선택이라 할지라도 엔지니어가 동료가 되는 데 도움이 되는 컨텍스트와 지식을 어떻게 공유할 수 있습니까? 그 길을 따라가다 보면 뭔가를 발견할 수 있습니다 . 디자이너가 항상 옳은 것은 아닙니다. 틀려도 괜찮아 디자이너가 성공하기 위해 완벽하고 창의적인 천재일 필요는 없습니다. 대신, 그들은 더 큰 것을 만들기 위해 다른 사람들의 의견과 아이디어에 의존 할 수 있습니다. 다음 엔지니어들이 함께 작업하기를 선호하는 방식을 고려하십시오. "저는 제 영역이 기술적이라는 것을 알고 있으며 시스템 아키텍처에 대한 지식을 사용하여 더 나은 솔루션을 제공할 수 있는 순간이 있습니다." 나는 이것을 "때때로 디자이너는 그들의 머리를 넘어섰고 나는 기꺼이 도와드리겠습니다."라고 말하는 매우 정중한 방법으로 읽었습니다. 그래서 그들을 보자! 또 다른 엔지니어는 “이의가 사실이고 디자이너가 놓친 부분이 있다면 변경 사항을 수용하라”고 지적했다. 이것은 매우 간단합니다. 피드백이 맞다면 그냥 하세요! 함께 일할 의향이 있다는 반복적인 표현은 팀의 각 상호 작용을 점진적으로 향상시킬 수 있습니다. 나머지 팀이 당신에게 같은 호의를 돌려준다면 당신은 아마 그 팀에서 좋은 시간을 보낼 것입니다. 마무리 모든 팀이 설계와 개발 통합의 완벽하고 조화로운 균형을 유지하는 것은 아닙니다(저에게는 어려운 팀이 꽤 있었습니다). 어떤 이유에서든 개발자와 디자이너는 종종 불필요하게 서로 적대감 을 나타냅니다. 이러한 통찰력은 이야기의 다른 면을 드러냅니다. 나는 이 두 팀이 같은 목표를 가지고 있고 그 결과에 도달하기 위해 서로를 지원할 자격이 있다고 생각합니다. 이 통찰력이 유용하다고 생각하셨다면 Twitter에서 사랑을 표현하거나 공유하는 것을 고려해 보시기 바랍니다.