디자인 시스템이 어디에서나 이메일 팀을 지원하는 방법: 웨비나 녹화 + Q&A

원격 이메일 팀과 협력하든 그렇지 않든 이메일 디자인 시스템이 도움이 될 수 있습니다. 프로그램을 확장하고 일관성을 보장하는 것부터 이메일을 디자인하고 코딩할 때 시간을 절약하는 것까지 강력한 디자인 시스템이 여러분을 지원합니다. 하지만 어떻게 만들고 유지 관리하기 시작합니까?

이 원탁 토론에서 Stack Overflow, Zillow 및 Litmus의 전문가들은 이메일 디자인 시스템 사용의 이점과 과제에 대해 이야기했습니다.

웨비나를 생중계로 볼 기회가 없으셨나요? 걱정하지 마세요. 언제든지 전체 녹음에 액세스할 수 있으며 아래 Q&A를 읽을 수 있습니다.

Q&A

웨비나 중에 질문을 해주신 모든 분들께 진심으로 감사드립니다! 다음은 가장 인기 있는 질문에 대한 답변과 라이브 웨비나에서 얻지 못한 질문에 대한 요약입니다. 추가 질문이 있습니까? 댓글에 남겨주세요.

팀을 시작할 수 있는 이메일 디자인 시스템의 핵심 모듈/구성 요소는 무엇입니까?

Ted Goas: 이것은 팀마다 다릅니다. 우리는 감사로 시작하여 사람들을 Google 문서에서 브레인스토밍하도록 초대했습니다. 모든 이메일에 필요한 몇 가지 안전한 항목(버튼, 타이포그래피 등)이 있을 수 있지만 감사 및 브레인스토밍 세션 후에야 우리가 무엇부터 시작해야 하는지 알 수 있었습니다. 이 출발점은 팀마다 다릅니다. 나는 이에 대해 "강의 3: 작게 시작하고 다른 사람들을 일찍 참여시키십시오." 섹션의 이메일 디자인 시스템 기사에서 이에 대해 썼습니다.

Jaina Mistry: Ted의 의견에 동의하고 Litmus에서도 같은 방식으로 시작했습니다. 현재 이메일을 감사하여 우리가 자주 반복하는 모듈과 구성 요소를 확인하는 것부터 시작했습니다. 우리에게 그것은 CTA 버튼, 단락, 목록(순서가 있는 것과 없는 것), 영웅 이미지, 링크 및 타이포그래피로 밝혀졌습니다.

Crystal Ledesma: 시작은 언급된 나머지 그룹과 마찬가지로 이메일을 감사하는 것만큼 간단합니다. 많은 양의 이메일을 보내고 모두 감사하는 것이 너무 큰 작업이라면 일반적으로 사용되는 디자인 패턴 및/또는 높은 성과를 내는 이메일을 식별하고 감사하십시오. 나는 물건을 손에 들고 감사한 이메일을 인쇄하고(죄송합니다!), 펜을 들고 우리가 계속해서 보게 되는 디자인 패턴을 식별하는 데 도움을 주기 위해 그 위에 그림을 그리는 것을 좋아합니다. 그것들은 시스템의 "빌딩 블록" 또는 모듈이 됩니다. Zillow의 이메일 디자인 시스템은 그렇게 시작되었습니다. 버튼과 같은 더 작은 구성 요소와 모든 이메일에서 일관성을 유지하는 방법을 알고 싶었지만 여전히 외부로 나가기 위해 노력하고 있었고 처음에는 한 팀이었기 때문에 단순하게 유지했습니다.

이메일 디자인 시스템을 실제로 구축하는 것에 대해 교차 기능 파트너로부터 동의를 얻은 후 이를 시작하기 위한 첫 번째 단계로 무엇을 추천하시겠습니까?

제이나: 목표로 삼을 현실적인 목표를 설정하세요. 달력을 보고 특정 날짜까지 달성하고자 하는 것을 계획하십시오. 이메일 마케팅 담당자는 바쁜 사람들이므로 디자인 시스템 작업과 일상 업무의 균형을 맞추게 될 것입니다. 디자인 시스템 작업에 전념할 시간이 없을 때도 있습니다. 몇 주 만에 완료하기로 설정했다면 매일 작업하지 않을 때마다 상당히 부정적인 느낌이 들 것입니다. 대신 달성하고자 하는 것을 덩어리로 나누고 조금씩 해결하십시오.

Crystal: 디자인 시스템을 사용할 사람들을 식별하고 이메일 디자인 시스템을 프로젝트가 아니라 내부 제품으로 생각하기 시작합니다. 식별한 사람들은 사용자입니다. 당신은 사용자 피드백을 일찍 받고 싶어하며, 보너스는 시스템에 대한 신뢰를 조성하는 데 도움이 됩니다. 그 외에도 다른 사람들의 조언을 반영합니다. 디자인 시스템의 장점은 시간이 지남에 따라 진화하고 확장할 수 있다는 것입니다. 작게 유지하는 것이 일을 진행하는 가장 좋은 방법입니다.

다양한 브랜드를 보유한 마케팅 대행사의 디자인 시스템은 어떤 모습일까요?

Crystal: 다양한 브랜드와 작업할 때 힘든 부분은 시각적으로 다양한 요구 사항이 있을 수 있으며 구독자 이메일 받은 편지함 및 구독자 행동도 다양하다는 것입니다. Zillow에는 더 잘 알려진 B2C 브랜드가 있지만 여러 B2B 브랜드도 있습니다. 이는 우리가 매우 광범위하고 다양한 가입자, 콘텐츠, 요구 사항 및 받은 편지함 그룹과 협력하고 있음을 의미합니다. 우리는 모든 브랜드에 대해 하나의 이메일 디자인 시스템을 갖기 위해 노력하고 있지만 각 브랜드에도 고유한 요구 사항이 있다는 것을 알고 있습니다. 각 브랜드의 특정 요구 사항에 고유한 시스템 분기가 있는 "핵심" 이메일 디자인 시스템을 갖게 됩니다. 에이전시 환경에서도 구조가 도움이 될 수 있다고 생각합니다.

팀에 전담 디자인 시스템 코디네이터가 없는 경우 템플릿 내에서 브랜드와 디자인 일관성을 유지하는 책임이 이메일 개발자나 디자이너에게 더 있다고 생각하십니까?

Jaina: 개발자와 디자이너라고 할 수 있습니다. 개발자는 기술적으로 달성할 수 있는 것에 대해 말할 수 있는 반면 디자이너는 접근성과 같은 문제를 해결하는 데 도움을 줄 수 있습니다. 어느 역할도 단독으로 그 책임을 맡을 수 없으며 함께 일해야 합니다.

Crystal: 디자인 시스템을 관리하고 하나의 브랜드만 작업하기 전에는 확실히 그룹 작업이었습니다. 디자이너와 개발자 모두 브랜드와 일관성을 유지하기 위해 함께 일했습니다. 제가 관리를 하고 있는 지금도 Zillow는 큰 회사이기 때문에 계속해서 그룹 활동을 하게 될 것입니다. 사용자를 디자인 시스템 및 문서에 온보딩하는 것과 같은 것은 일관성을 유지하고 브랜드를 유지하는 방법에 대해 교육하는 데 도움이 되므로 스스로 수행할 수 있는 권한을 부여할 수 있습니다. 우리 팀은 파트너 팀이 불확실할 수 있는 경우 이동하는 전문가의 역할을 더 많이 합니다. 회사에 우리와 같은 팀이 없더라도 Ted가 Stack Overflow에서 설명한 것과 유사한 관심 있는 자원 봉사자와 함께 이 작업을 수행할 수 있습니다.

얼마나 자주 새 구성 요소가 시스템에 추가되고 시스템의 일부로 만들기 전에 A/B 테스트를 합니까?

Crystal: 지금까지는 필요에 따라 새로운 구성 요소와 모듈을 추가하고 있습니다. 일반적으로 이것은 오늘날 시스템에 존재하는 것과 잘 맞지 않는 콘텐츠에 대한 콘텐츠나 목표가 있을 때 발생합니다. 몇 번 이상 발생 하고 이에 대한 강력한 비즈니스 사례가 있는 경우 시스템의 공식 일부가 되어야 한다고 판단하여 생성합니다. 우리의 모듈과 구성 요소는 이전 설계를 기반으로 하기 때문에 시스템의 일부로 만들기 전에 각각을 A/B하지 않았습니다. 그러나 디자인을 시스템 형식으로 변환하면 이메일의 일부를 쉽게 A/B 테스트할 수 있으므로 우리 팀은 성능이 떨어지는 모듈을 보류하고 청중에게 더 나은 성능을 보이는 모듈을 강조 표시할 수 있었습니다. 가까운 장래에 시스템을 계속 발전시키고 새로운 디자인을 탐색함에 따라 A/B 테스트는 구성 요소가 시스템의 일부가 되기 전에 필요한 단계가 될 것입니다.

이메일 전문가가 아닌 사람들이 작성한 이메일의 품질을 어떻게 유지합니까?

Ted: 그것은 매일의 투쟁입니다! 이메일 디자인 시스템은 품질이 낮은 이메일이 절대 전송되지 않는다고 보장하지 않습니다. 전도와 가르침이 도움이 되지만 한 번에 도처에 있는 것은 불가능하며 방해자가 되기를 원하지 않습니다. 저는 대량 전송, 반복 이메일, 고객 경험의 중심점에서 전송되는 이메일에 집중하여 영향력을 극대화하려고 노력합니다.

크리스탈: 테드가 한 말! 특히 디자인 시스템이 완전히 새로운 것이라면 시간이 걸릴 것입니다. 그것을 만들고, 확립하고, 모든 사람을 온보딩하는 등의 시간입니다. 시간과 지속적인 지원으로 품질이 향상됩니다. 가지고 있는 도구에 따라 이러한 도구를 활용하여 품질을 그대로 유지하기 위해 미세 조정된 제어를 추가할 수 있습니다.

이메일의 상호 작용과 같은 것이 디자인 시스템에 어떻게 적용됩니까?

Ted: 12월에 대화형 이메일을 실험했습니다. 탐색은 성공했지만 당면한 UX 문제가 해결되지 않아 보류되었습니다. 그러나 계속 진행했다면 대화형 구성 요소를 다른 모든 구성 요소와 같이 취급했을 것입니다. 세 번 이상 사용하면 설계 시스템에 코드화되고 문서화되어야 합니다. 그때까지 구성 요소는 임시 디자인으로 처리됩니다.

Crystal: 우리는 아직 이메일과 디자인 시스템에서 상호 작용을 탐구할 수 없었지만 우리의 접근 방식은 Ted의 것과 같을 것이고 상호 작용 여부에 관계없이 구성 요소를 추가하는 것과 이미 유사합니다. 처음에는 임시 항목으로 간주되어 다시 필요할 경우 백 포켓에 저장됩니다. 대화형 구성 요소를 몇 번 이상 사용하기 시작하고 영향력이 있는 것으로 판명되면 사용 지침과 함께 시스템에 추가됩니다.

우리는 디자인 시스템을 구현하려고 시도했지만 브랜딩 팀에서 제대로 사용하도록 하기가 어렵습니다. 그런 다음 매번 새로운 이메일 디자인을 만들어야 합니다. 어떻게 대처합니까?

Jaina: 브랜딩 팀이 디자인 시스템을 사용하는 데 방해 가 되는 문제는 무엇입니까? 그들에게 피드백을 요청하고 이를 해결하는 데 어떻게 도움을 줄 수 있는지 이해하십시오. 브랜딩 팀이 자신의 의견을 듣고 있다고 느낀다면 디자인 시스템에 대한 동의를 얻는 데 도움이 될 것입니다.

Crystal : 이러한 유형의 어려움은 일반적으로 시스템에 대한 오해나 우리가 알지 못하는 팀의 필요성에 뿌리를 두고 있습니다. 시스템에 직접 적용되는지 여부에 관계없이 팀의 요구 사항, 목표 및 마찰 영역을 파악하십시오. 이러한 결과를 시스템과 연결하면 팀이 시스템을 적절하게 사용하지 못하도록 차단하는 시스템 자체에 무엇이 누락되었는지 또는 팀이 시스템을 성공적으로 사용해야 하는 온보딩 및 지원 영역을 더 잘 진단할 수 있습니다. .

이메일 디자이너로서 받은 피드백은 디자인 시스템이 이메일을 지루하게 보이게 만든다는 것입니다. 이메일을 흥미롭게 유지하면서도 디자인 시스템과 일관성을 유지하려면 어떻게 해야 합니까?

Ted: 우리는 이 문제를 역으로 겪었습니다. 사람들은 우리의 일상적인 시작 템플릿을 따라 오류를 범할 것입니다. 1년에 한 번 흰색 배경에 검은색 텍스트가 대부분인 주요 발표에 대한 몇 가지 첫 번째 초안을 보았습니다. 이에 대한 응답으로 우리는 사람들에게 독특한 것을 디자인하는 것이 좋고 과거에 어떻게 해왔는지 보여주는 섹션을 디자인 시스템에 만들었습니다.

Jaina: 디자인 시스템을 갖추면 더 많은 창의력을 발휘할 수 있습니다! 구조가 적절하면 디자이너는 콘텐츠를 어떻게 구조화해야 하는지 생각할 필요가 없지만 이메일에 사용된 이미지나 일러스트레이션과 이러한 자산이 이메일 사본을 보완하고 향상시키는 방법에 더 많은 시간을 할애할 수 있습니다. 여기서 나는 일반적으로 "박스형" 이메일이 큰 성공을 거두는 것을 볼 수 있습니다. 환상적인 카피와 디자인으로 지원되는 구조입니다.

Crystal: 디자이너가 시스템의 제약을 받지 않도록 하기 위해 다른 회사의 영감을 공유하고 이러한 디자인을 구성 요소로 나눌 수 있는 방법을 설명하는 것이 도움이 되었습니다. 디자이너가 영감을 주는 이메일을 공유하면 더욱 좋습니다. 시간이 허락한다면 디자인 시스템을 고려하지 않고 디자이너가 원하는 대로 이메일을 디자인하도록 하는 것도 좋습니다. 그들이 당신과 다시 만나도록 하고 궁극적으로 그 디자인을 시스템에 맞추기 위해 어떤 조정을 할 수 있는지 강조할 수 있습니다. 또한 이를 디자인 시스템이 더 간단한 이메일을 더 빨리 완료하는 데 도움이 될 것임을 강조할 기회로 사용할 수도 있습니다. 절약된 시간을 통해 설계자는 향후 시스템의 일부가 될 수 있는 테스트를 위해 새로운 디자인을 제안할 수 있는 기회와 현재 시스템에서 제공하는 것보다 더 많은 것이 필요한 캠페인에 대해 고유한 이메일 디자인을 제안하고 생성할 수 있는 더 많은 가용성을 제공할 것입니다.

디자인 시스템을 수정해야 할 때 어떤 일이 발생하고 업데이트 요청이 들어오면 어떻게 미루나요?

제이나: 아직 리트머스에서는 이런 적이 없었는데, "왜?"라고 묻고 싶습니다. 필요한 노력이 그만한 가치가 있는지 이해합니다.

Crystal: 모든 브랜드를 지원하도록 확장할 수 있도록 현재 시스템을 수정하고 있습니다. 이는 수정에 대한 중요한 비즈니스 사례의 극단적인 예이지만 수정 여부를 고려할 때 염두에 두어야 할 좋은 기준입니다. 시스템이 더 작고 하나의 브랜드만 지원했을 때 수정 이유에는 브랜드 변경과 접근성 향상을 위한 코드 업데이트가 포함되어 있었습니다. 둘 다 분명히 강력한 비즈니스 사례였습니다. 업데이트 요청이 더 큰 비즈니스 목표 또는 요구 사항에 기여한다면, 이는 앞으로 나아가겠다는 분명한 신호입니다. 명확하지 않은 경우 질문하십시오. 개정판의 사용 사례는 무엇입니까? 개정판은 시스템의 다른 모든 항목에 어떤 영향을 줍니까? 이 개정판은 요청자의 사용 사례에 매우 구체적이며 해당 사용 사례의 개정판은 다른 사용자에게 파괴적인 파급 효과를 일으키나요? 시스템 업데이트 작업을 하는 팀이나 사람이 수정할 시간이 있습니까? 즉시 필요합니까 아니면 기다릴 수 있습니까? 다시 말해, 제이나가 말했듯이 필요한 노력이 그만한 가치가 있습니까?

Ted: 제 이나가 말한 것을 바탕으로 그 이유와 시기를 묻고 싶습니다. 구성 요소가 어떻게 사용되며 언제 사용되는지 이해하고 싶습니다. 디자인 시스템 구성 요소의 가장 좋은 후보는 자주 재사용되는 것이므로 어떤 것이 얼마나 자주 사용될 것인지 이해하는 것이 중요합니다.