많은 소프트웨어 팀이 디자인을 애자일 프로세스에 효과적으로 통합하는 데 어려움을 겪습니다. 다른 팀과 긴밀하게 협력하지 않는 디자이너는 자신을 포함한 모든 관계자에게 추가 작업을 생성하는 경향이 있으며 제품 팀 내에서 유해한 지식 사일로를 만들 수 있습니다.
Atlassian은 공동 작업 방식으로 애자일 팀 전체를 디자인 프로세스에 통합합니다. 모든 관계자가 디자인 프로세스에 참여하도록 하여 문제에 대한 다양한 관점을 얻을 수 있으며 아이디어를 공유하기 위해 설명서에 의존하지 않습니다. 이 프레젠테이션에서는 다음 방법을 살펴봅니다.
- 전체 팀을 디자인 프로세스에 참여
- 디자인을 애자일 프로세스에 통합
- 더 빠른 테스트 및 아이디어 구상을 위한 고객 인사이트 확보
질문 및 답변
이 Q&A는 Atlassian이 사용하는 디자인 도구부터 Atlassian이 고객 피드백을 처리하는 방법에 이르기까지 다양합니다.
Q1: 디자이너와 개발자는 항상 다른 인력입니까? HTML5 및 최신 UI 기술 때문에 디자이너가 기본적인 코딩 스킬을 갖추지 않기가 어렵습니까?
A1: 디자이너와 개발자 사이의 경계가 흐려지고 있습니다. Atlassian에는 엔지니어링 배경을 가진 디자이너도 있고 코드 라인을 작성할 수 없는 디자이너도 있습니다. 우리는 강력한 시각적 디자이너, 정보 아키텍트 및 진행자를 보유하고 있습니다. 모든 관계자는 서로 다른 강점을 보유하며 팀에서 이 강점을 인식하고 활용하는 것이 중요합니다.
Q2: 제품 팀 외부의 인력이 마케팅과 같은 디자인 워크숍에 참여하고 있습니까?
A2: 워크숍에는 다양한 분야의 인력이 포함되지만 그곳에 모이는 인력은 모두 이유가 있습니다. 일반적으로 PM, 엔지니어링 및 디자인 담당자가 있지만 다른 관점을 추가할 수 있다면 지원이나 마케팅에서 누군가를 불러올 수도 있습니다.
워크숍은 며칠 동안 진행될 수 있으며, 전념하기에 충분히 긴 시간입니다. 여러분이 가치를 더할 수 있는 세션과 몇 시간 동안 자리를 비울 수 있는 세션을 알 수 있도록 어젠더를 미리 공유하겠습니다. 하지만 핵심 그룹은 항상 참석해야 합니다.
Q3: 어떻게 구성원이 스케치를 하고, 드로잉에 참여하며 아이디어를 내놓도록 했습니까? 제품 소유자와 개발자가 두려움 또는 다른 이유로 인해 작업에 참여하기를 꺼려 한다는 느낌이 듭니다.
A3: 그룹과 아이디어를 공유해야 한다는 것이 이미 위협적이지만 공개적으로 그림을 그리는 것은 훨씬 더 무섭습니다. 그래서 저는 이 워크숍 단계에서 대규모 그룹을 쌍으로 나누기를 좋아합니다. 그러면 빈 종이 한 장에서 느껴지는 부담을 줄일 수 있습니다. 또한 서로 아이디어를 주고받고 추진력을 유지할 수 있습니다.
이 세션 중 하나에 참여한 후 모두가 프로세스에 익숙해지며 참여하기를 매우 좋아한다는 것을 알았습니다. 방에서 훌륭한 대화가 많이 진행되어 항상 알림이 울립니다.
모두에게 걸작을 그릴 필요가 없다고 알리는 것도 중요합니다. 인터페이스 스케치, 다이어그램 또는 글머리 기호 목록 등을 통해 아이디어를 시각화하기만 하면 나머지 그룹이 공통된 이해를 얻을 수 있습니다. 종이에 아이디어를 담은 경우 워크숍이 끝난 후에도 참조용으로 보관할 수 있습니다.
Q4: 디자인 팀의 새로운 팀원을 어떻게 최신 상태로 만들 수 있습니까?
A4: 우리는 모든 신입 디자인 팀원을 위한 온보딩 프로세스를 보유하고 있습니다. 프로세스는 Atlassian에서의 디자인 소개, 프로세스 및 나머지 제품 팀과의 협력 방식에서 시작됩니다. 우리가 개발한 디자인 원칙을 자세히 살펴보고 이 원칙이 적용되는 예제를 보여줍니다. 페르소나, Atlassian 디자인 가이드라인, 플레이북과 같은 디자인 리소스에 대해 자세히 알아볼 수 있는 부트 캠프 수업이 있습니다.
또한 처음 몇 주 동안 새로운 디자이너들이 친구와 짝을 이루어 요령을 보여주고 더 많은 책임에 쉽게 녹아들게 합니다.
새로운 디자이너의 적응 속도를 높이는 또 다른 방법은 첫 주에 워크숍에 데려오는 것입니다. 제품 팀을 만나 우리가 함께 일하는 방식을 직접 경험할 수 있는 좋은 방법입니다. 처음 몇 달 동안 배워야 할 것이 많지만 워크숍은 아주 작은 문제를 해결하기에 좋은 장소입니다.
Q5: 어떤 고객 조사 방법이 가장 유용하다고 생각하십니까? 현장 연구, 관찰, 사용성 또는 기타 방법입니까?
A5: 모든 유형의 고객 조사가 유용하다고 생각하지만 프로젝트의 여러 단계에서 다양한 유형의 연구가 수행됩니다.
예를 들어, 프로젝트를 시작할 때는 문제와 관계자들이 작업하는 컨텍스트를 완전히 이해하려고 합니다. 상황별 문의는 여기서 정말 유용합니다. 팀이 일하는 장소에 방문하여 그들의 프로세스, 문제가 미치는 영향 및 더 효과적이기 위해 필요한 사항에 대해 이야기합니다. 그들이 작업을 달성하려고 노력하는 방법과 마주하는 좌절감을 직접 보는 것이 좋습니다.
사용자 테스트 및 고객 인터뷰는 아이디어를 조금 더 발전시켰을 때 유용합니다. 간단한 프로토타입을 사용하여 흐름을 살펴보는 관계자를 보거나 그저 제안된 솔루션에 대해 대화를 나눠도 귀중한 인사이트를 얻을 수 있습니다.
반면에 A/B 테스트는 솔루션이 얼마나 효과적인지 측정할 수 있는 멋진 방법입니다.
Q6: Atlassian 디자이너들은 어떤 도구를 사용합니까?
A6: Atlassian 디자이너는 작업에 적합한 도구를 사용합니다. 아날로그 방식인 펜과 종이일 수도 있고 HTML 및 CSS일 수도 있습니다.
고충실도 디자인을 만들기 위해 대부분의 팀은 Sketch를 사용하지만 Adobe 제품군도 사용합니다. Atlassian 패턴 라이브러리의 모든 UI 요소는 벡터 개체로 만들어졌으므로 기본 레이아웃을 조합하여 그 위에 구축하기가 매우 간단합니다. 간단한 프로토타이핑을 위해 InVision 또는 Marvel을 사용합니다. 더 복잡한 상호 작용의 경우 Framer Studio, Origami, Axure 또는 직접 작성한 코드를 사용합니다.
또한 포스트잇 메모지와 화이트보드 마커도 많이 사용합니다. :)
Q7: 애자일 프레임워크 내에서 작업할 때 직면하는 과제에는 어떤 것이 있습니까?
A7: 완벽을 버리고 대신 빠르고 반복적인 작업을 만드는 법을 배우는 것이 가장 큰 과제입니다. 디자이너는 항상 고품질 작품을 만들고 싶지만 90%인 제품을 제공한 다음 개선하는 것에도 만족해야 합니다.
Q8: 설명서를 줄이는 몇 가지 방법을 언급했습니다. 어떤 형태의 설명서를 유지하고 있습니까? 모든 설명서를 제거하셨습니까?
A8: Confluence를 사용하여 진행 중인 작업을 공유하고 폭넓은 팀으로부터 피드백을 수집합니다. 일반적인 페이지에는 해결하려는 문제와 제안된 솔루션이 제공하는 가치에 대한 몇 가지 컨텍스트가 포함됩니다. 페이지에는 솔루션을 설명하기 위한 스케치 사진, 고충실도 모형 또는 프로토타입 링크가 포함되어 있습니다. 사용자들은 댓글과 질문을 추가하고 디자이너는 프로젝트가 진행되면 업데이트된 디자인을 게시합니다. 하지만 이것은 실제로 '설명서 유지'가 아니라 디자인 자산과 피드백을 수집하며 진화하는 페이지입니다.
Q9: 팀이 공동 배치되지 않은 경우 분산된 디자인에 어떻게 접근합니까?
A9: Atlassian은 글로벌 회사이므로 분산된 팀과 협업하는 것은 우리가 매일 마주하는 일입니다. Jira에는 시드니, 그단스크 및 호찌민에 팀이 있으며 항상 격차를 해소할 방법을 찾고 있습니다. 기술은 큰 도움이 됩니다. 우리는 화상 통화 및 메시징에 Hipchat을 사용하고 Confluence를 사용하여 작업을 게시하고 공유하며 댓글을 추가합니다. 또한 Jira를 사용하여 모든 작업을 체계화합니다. 하지만 이것은 완벽하지는 않으며 그 무엇도 대면 커뮤니케이션을 대체할 수는 없습니다. 프로젝트에서 중요한 부분의 경우 가능하면 관계자들을 같은 공간에 모으려고 노력합니다. 불가능할 경우 원격 팀원과 과하다 싶을 정도로 커뮤니케이션하며 최선을 다해 모든 정보를 공유하는 것이 좋습니다.
Q10: '고객 피드백'으로 가장하는 '노이즈'를 어떻게 제어하고 필터링합니까?
A10: 우리는 고객 피드백을 많이 받고 있습니다. 사용자 댓글을 수집하여 Jira 프로젝트에 이슈로 저장하는 피드백 도구가 있습니다. 저는 커피를 마시며 최신 이슈를 읽으면서 하루를 시작합니다. 댓글을 살펴보는 동안 떠오르는 일반적인 테마나 패턴을 기록하고 레이블을 추가하여 그룹화합니다. 이 레이블을 사용하여 모든 피드백을 필터링하면 얼마나 많은 사용자가 비슷한 문제를 제기했는지 확인할 수 있습니다. 그런 다음 패턴이 확립되면 해결할 수 있는 특정 사용 사례와 함께 이 문제를 제품 팀에 전달할 수 있습니다.
