개발자는 코드를 "소유"하므로 디자이너는 경험을 "소유"해야 하지 않습니까?

우리는 모두 거기에 있었다. 비즈니스 요구 사항을 수집하고, 복잡한 사용자 여정을 작성하고, 정밀한 인터페이스 요소를 만들고, 대표적인 사용자 샘플에서 테스트하는 데 몇 달을 보냈지만 원하는 경험과 거의 유사하지 않은 최종 제품 을 보았습니다.

조직이 준비되지 않았다는 믿음에도 불구하고 더 강력하고 민첩한 접근 방식을 고집했어야 했을까요? 아마도 개발자가 5가지 다른 변형 캐러셀을 만드는 대신 모듈식 코드 라이브러리를 사용하도록 하여 패턴 포트폴리오를 더 잘 수행해야 했을 것입니다. 또는 매일 개발 팀 옆에 앉아 설계한 내용이 실제로 구현되었는지 확인해야 했을 수도 있습니다.

SmashingMag에 대한 추가 정보:

• 디자인 프로세스에 개발자를 포함시켜야 하는 이유
• 반응형 디자인의 팀 협업 및 효율성 격차 해소
• 멋진 디자이너와 개발자
• 개발자와 효과적으로 의사 소통하는 방법

대신 모든 미묘함을 제거한 뒤섞인 UI 요소만 남게 됩니다. 그들은 당신이 기본 애니메이션 라이브러리에 드롭하기 위해 올바른 전환을 얻기 위해 며칠 동안 일하는 것을 볼 수 없었습니까? 그리고 그 추가 체크 아웃 단계는 도대체 어디에서 왔습니까? 나는 마케팅이 마지막 순간에 그것을 던졌습니다. 통합이 어렵고 타협이 필요하다는 것을 알고 있었지만 기술 팀이 아니라 여기에서 사용자의 삶을 더 쉽게 만들어야 합니다 .

물론, 사이트가 이런 식으로 된 데에는 많은 이유가 있습니다. 다양한 수준의 기술을 가진 서로 다른 팀이 프로젝트의 다른 부분에서 작업하고, 개발 주기를 단축하는 막판 변경 사항이 많고, 기술적인 문제가 많습니다. 그런데도 왜 개발팀이 와서 UI 변경에 대한 조언을 구하지 못했을까요? 당신은 그들의 코드를 엉망으로 만들지 않는데 왜 그들이 당신의 디자인을 바꿔야 합니까? 특히 비즈니스 영향이 클 수 있는 경우! 당신은 모퉁이만 돌았고 그들이 방금 요청했다면 기꺼이 도왔을 것입니다.

위의 이야기는 허구일 수 있지만, 사내든 에이전시든 디자인 세계의 모든 구석에서 들은 감정입니다. 세심하게 제작된 경험이 강력한 개발 팀에 의해 망가졌습니다.

이 경험은 내가 몇 년 전에 미국 지역 뉴스 채널에서 본 뉴스 기사를 생각나게 합니다. 한 카운티 박람회에서 마지막으로 손을 픽업트럭에 싣고 남은 사람이 상을 받는 지구력 대회가 열리고 있었습니다. 저는 종종 디자인이 "트럭 터치"라는 대규모 게임과 같다고 생각합니다. 개발 팀은 항상 콘테스트가 끝날 때 키를 가지고 떠나갑니다. 논쟁의 마지막 단어와 마찬가지로 사이트와 마지막으로 접촉하는 사람이 모든 권한을 가지며 작동 방식이나 모양을 결정할 수 있습니다. 특히 그들이 특정 목표 경험이 "기술적으로 가능"하지 않다고 주장하는 경우, 이는 종종 "정말 어렵다", "나는 그렇게 하는 것을 귀찮게 할 수 없습니다" 또는 "더 좋은 방법이 있다고 생각합니다"의 줄임말입니다. 그래서 개발자 카드를 뽑을 것입니다."

이제 내가 여기 개발자들에게 부당하게 가혹한 태도를 취하고 있다는 것을 알고 있으며 그렇게 할 의도는 없습니다. 사용성에 정말 관심을 갖고 사용자를 위해 최선을 다하는 놀랍도록 재능 있는 기술자가 있습니다. 그러나 디자인은 쉽고 누구나 의견을 가질 수 있는 반면 개발은 어렵고 특별히 시작한 사람만 할 수 있다는 믿음으로 인해 학문 간의 비대칭적 존중이 있는 것처럼 느껴질 때가 많습니다. 따라서 디자이너는 디자인 프로세스에 모든 사람을 참여시키도록 권장되지만(때로는 예상됨) 동일한 사치를 누릴 수 없는 경우가 많습니다.

솔직히 말해서, 나는 그들을 비난하지 않습니다. 결국, 나는 위험할 만큼의 개발을 알고 있으므로 데이터베이스 구조와 코드 성능에 대한 내 의견을 원했다면 바보가 될 것입니다. 그런 다음 다시 나는 개발자가 언제 무언가를 날조하는지 알 수 있을 만큼 충분히 알고 있으며, 불가능하거나 구현하는 데 몇 달이 걸린다고 말한 작업의 프로토타입으로 개발자에게 돌아가는 것은 항상 재미있습니다.

문제는 많은 개발자들이 디자인에 대해 같은 입장에 있다고 생각합니다. 그들은 단지 그것을 깨닫지 못합니다. 따라서 몇 년 전 회의에서 들은 내용을 기반으로 인터페이스 요소를 변경할 때 중요한 컨텍스트가 부족할 수 있습니다. 아마도 이것은 성능이 좋지 않았기 때문에 이미 테스트하고 할인한 것일 수 있습니다. 아마도 접근성과 같은 특정 이유로 이 요소를 다른 요소보다 선택했습니까? 아니면 평균적인 Jo가 아닌 수퍼유저로서 웹을 경험하는 방식에 따라 개발자의 의견이 틀렸을 수도 있습니다.

이제 여기서 바로 알아보겠습니다. 개발자가 디자인에 관심을 보이거나 디자인 프로세스에 입력해서는 안 된다는 말은 아닙니다. 저는 교차 기능 페어링에 대한 확고한 신봉자이며 최고의 사용성 솔루션 중 일부는 기술 팀에서 나온다고 생각합니다. 또한 다양한 분야에 걸쳐 재능있는 사람들이 많이 있습니다. 그러나 어느 시점에서 경험은 소유되어야 하며 HTML 파일을 열고 "트럭을 만지는" 마지막 사람이 경험을 소유해서는 안 된다고 생각합니다.

따라서 훌륭한 디자이너가 훌륭한 개발자가 제공하는 기술과 경험을 존중한다면 약간의 패리티는 어떻습니까? 디자이너가 개발자가 "코드를 소유"하는 것을 기쁘게 생각한다면 비슷한 존경심을 표시 하고 디자이너가 "경험을 소유"하게 하지 않겠습니까?

이 작업은 매우 간단합니다. 특정 방식으로 디자인된 이유가 확실하지 않은 상황에서 더 잘할 수 있다고 생각하는 경우 그냥 뛰어들어 변경을 시작하지 마십시오 . 마찬가지로, 기술적인 장애물에 부딪혀 다른 방식으로 디자인하는 것이 삶을 더 쉽게 만들어 줄 것이라고 생각한다면 디자이너와 상의하십시오. 그들은 당신이 제안한 변경 사항에 절대적으로 괜찮을 수도 있고, 같은 문제를 해결하는 다른 방법에 대해 생각하고 싶어할 수도 있습니다.

결국 협업은 양방향으로 진행됩니다. 따라서 디자이너가 버전 제어 프로세스 외부의 라이브 서버에서 코드 "최적화"를 시작하지 않도록 하려면 디자인에 대해 동일한 작업을 수행하지 마십시오.