(영상) 서비스디자인 101 - Victor Diaz Zapanta, Liz Fox. Skylight 공공서비스디자인컨퍼런스2023

Skylight는 2023년 공공 서비스디자인 컨퍼런스의 오프닝 세션(“Service Design 101”)에서 서비스디자인의 정의, 필요성, 적용 프레임워크(착수–발견–전략화–실험–구현)가 소개했다. 발표자 빅터 디아스 사판타와 리즈 폭스는 CDC의 SimpleReport 사례를 통해 요양시설·학교 현장의 검사결과 보고를 간소화하고 서비스 블루프린트·온보딩 개선·신원확인 자동화(Experian 연계)로 도입 규모를 크게 확장한 과정을 공유했다. 

Service Design 101 - Skylight's Public Service Design Conference 2023
* Service Design 101에서 101은 ‘입문/개론’ 수준을 말함. 북미 대학에서 과목 번호로 쓰이는 체계에서 101은 전공의 가장 기초 과목을 의미함(예: Economics 101 = 경제학 개론)
* Skylight's Public Service Design Conference 2023 : 2023년 민간 디지털 컨설팅 회사(LLC)인 Skylight가 주관한 공공 부문을 위한 서비스디자인 컨퍼런스. Skylight는 주로 정부기관과 협업해 공공서비스의 디지털 전환·디자인을 지원하는 기업이다. 

출처: Skylight  http://youtube.com/@skylight.digital
원본 영상 : https://youtu.be/FxGEeE3XElU?si=wzp9H7F-dWlOBYRK  
번역 : 챗GPT (요약, 생략된 부분, 발언자 표기 오류가 있을 수 있습니다. 원본을 확인해주세요.)  

Service Design 101 - Skylight의 공공 서비스 디자인 컨퍼런스 2023
Victor Diaz Zapanta, Liz Fox
2023. 6. 3.

유튜브 설명글 : 
본 컨퍼런스의 오프닝 발표로, 서비스디자인의 전반을 다루는 무대를 마련합니다. 서비스디자인이 무엇인지, 어떤 문제를 해결하는지, 언제 필요함을 알 수 있는지, 그리고 실무에 적용하기 위한 프레임워크를 소개합니다.
콘텐츠 주의: 이 영상에 소개된 사례 중 하나는 코로나19 팬데믹 초기, 공동 거주시설(congregate care facilities)을 지원한 Skylight의 작업과 당시 그 환경에서의 높은 스트레스 상황을 간략히 언급합니다.
슬라이드 및 컨퍼런스 발표 자료: http://bit.ly/3Ndvthw
Skylight의 서비스디자인 프레임워크: http://skylight.digital/work/toolkits/service-design-framework/  
자세한 문의: hello@skylight.digital

발표자( Presenters ):

빅터 디아스 사판타 Victor Diaz Zapanta: Skylight의 수석 사용자 연구원(Principal User Researcher)입니다. CDC의 코로나19 검사 보고를 지원하는 애플리케이션인 SimpleReport와 함께 일하고 있습니다. 정치 및 정부 분야에서 10년이 넘는 디지털 경험을 보유하고 있으며, 사용자 중심 디자인 프로세스의 강력한 옹호자입니다. 미국 시민권 첫 디지털 신청 시스템 구축을 도왔고, 정부 투명성 웹사이트 FOIA.gov의 디자인과 리서치를 이끌었으며, 18F 방법 카드 프로젝트 출시에 기여했습니다. 또한 소비자금융보호국(CFPB)의 Technology+Innovation 팀 창립 멤버였습니다.

리즈 폭스 Liz Fox: Skylight의 스태프 프로덕트 디자이너(Staff Product Designer)입니다. 미 공군의 BESPIN( Business Enterprise Systems Product INnovation ) 디자인 스튜디오와 함께 일하고 있습니다. 엔터프라이즈 소프트웨어 분야에서 9년을 버텨온 폭넓은 UX 제너럴리스트로, 이해관계자가 많고 자원은 적으며 구조와 감독이 느슨하고 정치적 요인이 많은 모호한 문제 영역을 다루는 것을 즐깁니다. 이전에는 Salesforce와 TripIt(Concur, SAP 계열)에서 근무했습니다. 그 이전에는 노스캐롤라이나 대학교 채플힐(UNC-Chapel Hill)에서 라틴아메리카 미술사를 연구·강의했으며, 그보다 더 이전에는 고릴라 복장을 하고 풍선을 배달했습니다.

---

 

CHERYL HAMMOND 37:56

곧 서비스 디자인 101 세션을 시작할 예정입니다. 이에 앞서 제가 가장 좋아하는 동료 두 분을 소개하겠습니다. 사실 비밀이지만, 제 동료들은 모두 제가 가장 좋아하는 동료들입니다. 오늘은 저희와 함께하는 수석 사용자 연구원 빅터 디아스 사판타입니다. 빅터는 서비스디자이너로서도 탄탄한 경력을 가지고 있습니다. 그리고 저희의 프로덕트 디자이너인 리즈 폭스입니다. 두 분이 서비스디자인의 기초를 배우는 데 도움을 주실 것입니다. 이제 슬라이드 공유를 멈추고 두 분께 넘기겠습니다. 모두 감사합니다. 발표 중에는 채팅에 질문을 자유롭게 남겨 주시기 바랍니다. 제가 채팅을 모니터링하고 시간이 될 때 발표자분들께 드릴 질문을 선별하겠습니다. 빅터와 리즈, 시작해 주시기 바랍니다.

VICTOR ZAPANTA 38:42

여러분, 안녕하세요. 이제 제 슬라이드가 보이실 것입니다.

CHERYL HAMMOND

아주 잘 보입니다.

VICTOR ZAPANTA

좋습니다. 셰릴, 정말 감사합니다. 제 이름은 빅터 사판타입니다. 오늘 여러분과 이야기하게 되어 매우 기쁩니다. 동시에 꽤 긴장도 하고 있어서 양해를 부탁드립니다. 줌에서 한 손에 꼽을 정도의 동료 이상과 이야기한 지가 좀 되었기 때문입니다. 그렇지만, 지난 4년 반 동안 스카이라이트에서 공중보건 프로젝트를 수행할 영광을 누렸습니다. 제가 시민 기술 분야에서 일한 지도 12년이 넘었는데, 이렇게 소리 내어 말하니 놀랍기만 합니다. 저는 2010년에 소비자금융보호국(CFPB)에서 시민 기술 분야를 시작했고, 당시 초창기 디자이너 중 한 명이었습니다. CFPB에서 4년간 근무한 뒤 18F에 합류해 또 4년을 일했으며, 그 이후로는 계속 스카이라이트에서 일하고 있습니다. 이제 리즈에게 자기소개 기회를 드리겠습니다.

LIZ FOX 39:39

안녕하세요, 저는 리즈입니다. 저도 스카이라이트의 디자이너입니다. 스카이라이트에서는 국방 서비스 측면의 일을 하고 있으며, 공군 산하 BESPIN 소프트웨어 팩토리의 일부인 디자인 스튜디오와 함께 일합니다. 제가 ‘베스핀’이라고 말하는 것을 들으셨다면 아시겠지만, 공군은 스타워즈에서 이름을 따오는 일을 정말 멈추지 않습니다. 절대 멈추지 않습니다. 제가 하는 일은 현장에서 장병들이 업무 중에 디자인을 할 수 있도록 가르치는 것입니다. 정말 재미있습니다. 공군과 함께 일하는 동안 서비스디자인 프로젝트를 몇 건 수행할 기회가 있었고, 그중 일부를 오늘 조금 공유할 수 있기를 바랍니다. 이제 말을 멈추고, 빅터에게 다시 넘기겠습니다.

VICTOR ZAPANTA 40:16

좋습니다. 발표 내내 채팅에 질문을 남겨 주시기를 부탁드리며, 저희도 가능한 한 중간중간 멈춰서 질문에 답하도록 하겠습니다.

서비스디자인이란 무엇입니까? 그 질문으로 바로 들어가기 전에, 도움이 될 만한 이야기를 하나 먼저 드리고자 합니다. 오늘 아침 제 출근길에 대해 간단히 말씀드리겠습니다. 그 과정에서 출근길 사진을 몇 장 보여드릴 텐데, 더 많은 맥락이 필요하시면 발표 자료를 내려받아 각 사진의 설명을 참고하시기 바랍니다.

저는 뉴욕시에 살고 있고, 매일 지하철을 타고 사무실로 갑니다. 매일 아침 로어 이스트 사이드의 아파트를 나와 집 모퉁이에 있는 델런시/에식스(Delancey/Essex) 역으로 걸어갑니다. 반 블록 떨어진 곳쯤에서 입구를 알리는 상징적인 녹색 램프 기둥이 보입니다. 에식스 스트리트 역 표지판과 이곳에 정차하는 열차를 알려주는 JZFM 표지판도 보입니다. 계단을 내려가 개집표기(턴스타일) 쪽으로 가면, 승강장 방향을 분명하게 안내하는 표지판이 있습니다. 휴대전화를 꺼내 터치 인디케이터에 대고 2.75달러 요금을 결제합니다. 저는 개인적으로 얼마나 기다려야 하는지 알고 싶은 편입니다. J 열차 표지판이 늘어선 승강장을 따라 내려가 가장 가까운 도착 안내 전광판으로 갑니다. 여기서 다음 열차가 약 1분 뒤 도착한다는 것을 볼 수 있습니다. 이 전광판은 또 그 열차가 제 사무실 방향인 브로드 스트리트 종착이라는 것도 알려줍니다. 그래서 제가 승강장의 맞은편이 아닌 올바른 쪽에 서 있다는 것을 압니다. 마침내 J 열차가 도착하고 저는 탑승합니다. 차내 디지털 표시는 제 목적지가 약 두 정거장 남았다고 알려줍니다. 몇 분 뒤 스피커에서 “여기는 캐널 스트리트입니다”라는 자동 안내 방송이 나오고, 우리가 역에 도착합니다. 저는 열차에서 내려 붉은색 출구 표지판을 향해 갑니다. 계단을 올라가 개집표기를 통과해 밖으로 나와, 몇 블록을 걸어 지금 제가 앉아 있는 이 컴퓨터 앞까지 옵니다. 이렇게 다소 평범한 이야기를 왜 하느냐고요? 저는 뉴욕 지하철 시스템이 서비스디자인의 훌륭한 사례라고 생각하기 때문입니다.

잘 실행된 서비스디자인은 사용자가 좋은 경험을 만들기 위해 무대 뒤에서 벌어지는 수많은 작동과 조정에 대해 거의 알지 못하는 상태를 말합니다. 지하철은 서로 연결된 시스템과 서비스의 오케스트라이며, 매일 400만 명의 뉴요커를 A 지점에서 B 지점으로 이동시키기 위해 모두가 함께 작동합니다. 뉴욕 지하철을 좋은 경험으로 만드는 보이지 않는 시스템은 정말 많습니다. 열차 문을 안전하게 조작하고 안내 방송을 하는 실제 기관사가 있고, 역 내 길찾기를 돕는 안내 사인을 설계·제작·유지하는 사람들이 있으며, 선로를 보수·정비하는 작업자들이 있습니다.

제가 특히 의존하는 시스템 중 하나는 도착 카운트다운 시계입니다. 이 시스템이 2018년에 전 노선으로 확대되었을 때는 완전히 판도를 바꾸는 변화였습니다. 그 전에는 열차를 얼마나 기다려야 하는지 알 수 있는 접근 가능한 방법이 사실상 없었습니다. 제가 도착 카운트다운 시계를 바라볼 때, 각 열차의 첫 차와 마지막 차에 현재 위치를 송신하도록 설치된 블루투스 비콘에 대해서는 아무것도 모릅니다. 선로에 설치된 비콘과 통신해 열차 위치를 추적하는 역 내 블루투스 수신기에 대해서도 모릅니다. 이런 수신기를 설치해야 했던, 이 사진 속과 같은 다른 작업자들에 대해서도 모릅니다. 열차가 2분 뒤에 오는지 20분 뒤에 오는지를 계산해 주는 소프트웨어에 대해서도 모릅니다. 이렇게 무대 뒤에서 사용자 경험을 좋게 만들기 위해 조율되고 작동하는 모든 것의 총합이 바로 서비스디자인입니다. 또한 MTA가 잘하는 점이 많지만, 개선이 필요한 영역도 부족하지 않다는 점을 덧붙이고 싶습니다. 특히 장애인이 지하철 시스템을 더 쉽게 이용할 수 있도록 하는 부분에서는 개선의 여지가 큽니다.

이제 다시 “서비스디자인이란 무엇인가”라는 질문으로 돌아가 보겠습니다. 서비스디자인은 인간중심디자인(HCD)의 하위 집합이라는 점을 강조하는 것이 중요합니다. HCD를 대체하는 것이 아니라, 문제의 성격에 따라 더 잘 맞을 수 있는 HCD의 구체적 접근법입니다. 특히 정부의 서비스 제공에서 우리가 자주 마주치는 문제 유형에 매우 유용한 접근이라고 생각합니다. 서비스디자인은 서비스를 총체적으로 설계하는 접근입니다. 서비스 이용자와 그들과 상호작용하는 서비스 제공자 모두에게 고품질 경험을 만들 수 있도록 조직을 돕습니다. 서비스디자인은 종종 직원 경험에 의도적으로 더 초점을 둡니다. 직원이 마주하는, 즉 백스테이지의 프로세스를 간소화하면 직원의 경험이 개선되고, 그 결과 사용자에게 더 나은 경험을 제공할 수 있게 됩니다.

이제 미국디지털서비스(USDS)와 스카이라이트가 서비스디자인을 활용하여 CDC의 코로나19 대응을 어떻게 도왔는지 살펴보겠습니다. 2020년을 떠올려 보시기 바랍니다. 팬데믹 초기, 시애틀 교외의 라이프 케어 센터에서 2월 26일 호흡기 질환으로 두 명의 거주자가 사망했습니다. 미국의 주요 도시들이 봉쇄되기 몇 주 전이었습니다. 당시에는 검사 접근성이 충분하지 않았고, 확진이 나오기까지 며칠이 걸렸습니다. 더 많은 거주자가 아프기 시작했고 직원들은 시설을 봉쇄했습니다. 직원들은 시설 입구에 안내문을 붙였습니다. “호흡기 질환이 집단 발생 중입니다 — 방문 금지”라고 적혀 있었습니다. 코로나 검사 결과가 나왔을 때에는, 시설 거주자의 3분의 2를 포함해 129명이 코로나 양성 판정을 받았습니다. 이는 팬데믹의 시작에 불과했습니다. 2021년 6월까지 전체 사망자의 3분의 1 이상이 요양 시설과 연관되는 상황을 보게 되었습니다. 집단 거주시설이라는 환경, 직원과 외부인의 잦은 출입, 그리고 이 질병이 60대 이상 성인에게 특히 치명적이었다는 사실이 장기 요양시설을 코로나19 팬데믹의 ‘제로지대’로 만들었습니다.

연방 의무에 따라, 미국에서 실시된 모든 코로나19 검사는 질병 확산을 억제하기 위한 조치를 취할 수 있도록 공중보건기관에 보고되어야 했습니다. 병원이나 의학 실험실 같은 곳은 이미 이러한 데이터를 보고하는 시스템을 갖추고 있었습니다. 그러나 실제로 검사가 이루어지던 많은 장소에는 이런 시스템은커녕 공중보건 부서로 데이터를 전달할 파이프라인조차 없었습니다.

잠시 상상해 보시기 바랍니다. 여러분이 이러한 요양시설 중 한 곳의 일선 종사자, 즉 간호사라고 가정해 보겠습니다. 인력은 부족하고, 동료들 다수가 코로나에 걸렸기 때문에 장시간 근무를 하고 있습니다. 양성 사례가 확인될 때마다 시설의 모든 직원과 모든 거주자를 검사해야 합니다. 이는 매주 수십, 많게는 수백 건의 검사를 수행하고, 그 모든 결과를 공중보건 당국에 보고해야 함을 의미합니다.

여기 2020년 4월의 코로나 사례 보고서 양식 예시가 있습니다. 여러분이 보유한 보고 메커니즘은 매우 수작업 위주입니다. 검사 하나하나마다 시설의 상세 정보를 입력해야 합니다. 환자의 이름, 주소, 생년월일 같은 인구통계 정보를 입력해야 하고, 환자가 검사받을 때마다 매번 이 정보를 입력해야 합니다. 검사 결과를 보고하는 일은 사실상 간호사의 본업에 더해진 풀타임 업무가 되어 버렸고, 이미 인력은 부족한 상태입니다. 코로나19 검사 결과 보고의 막대한 부담을 줄이는 일은 이러한 요양시설에 엄청난 가치를 제공할 것입니다. 바로 여기서 SimpleReport가 탄생했습니다. SimpleReport는 이러한 유형의 시설이 환자와 모든 직원의 명부를 시스템에 한 번 등록해 둘 수 있게 해주었습니다.

명부 정보가 시스템에 들어가면, 보건 종사자는 환자를 조회하고 현재 증상이 있는지 같은 관련 정보를 입력한 다음 검사 결과를 선택할 수 있습니다. SimpleReport는 자매 애플리케이션인 ReportStream을 통해 데이터를 공중보건 부서로 직접 전달했습니다. 이로 인해 요양시설에는 막대한 시간 절감 효과가 발생했습니다. 저희는 이것이 성공적이었다고 자부합니다. SimpleReport는 애리조나에서 시범 운영을 거친 뒤 2020년 12월에 출시되었고, 이번 주 월요일 기준으로 12,000개가 넘는 시설이 검사를 보고하고 있으며, 우리 플랫폼은 총 770만 건의 검사 이벤트를 기록했습니다.

출시 이후, 우리 팀은 초기의 요양시설과 장기 요양시설에 대한 초점을 넘어 연구 범위를 확장하고자 했습니다. SimpleReport의 강점은 고정된 명부의 사람들이 반복적으로 검사되는 시설에서의 검사 보고에 있었습니다. 그래서 우리는 K-12 학교가 SimpleReport 도입의 수혜를 볼 수 있는 영역이라고 빠르게 파악했습니다. 학교는 SimpleReport와 자연스럽게 잘 맞는 대상이었습니다. 2021년 초에는 많은 학교가 여전히 휴교 중이었지만, 가을이 되자 다수의 학교가 대면 수업을 재개하기 시작했습니다. 우리가 처음 SimpleReport를 만들 때는, 시설이 공중보건 당국에 데이터를 보고할 수 있도록 앱을 가동시키는 것이 최우선 과제였습니다. 이는 몇 가지 타협을 의미했는데, 그중 하나가 앱 온보딩 처리 방식이었습니다. SimpleReport 온보딩에는 2~4주가 걸렸고, 보건복지부(HHS) 직원과 직접 상호작용해야 하는 복잡한 다단계 프로세스였습니다. 학교가 개학하면서 예상되는 수요를 감당하기에는 기존 프로세스로는 확장성이 부족하다는 것이 분명했습니다. 대규모 사용자 유입을 지원하려면 무엇이 필요한지 이해하기 위해, 우리는 현재 온보딩 프로세스를 매핑하는 서비스 블루프린트 작성부터 시작했습니다.

VICTOR ZAPANTA 50:11

이 블루프린트는 2021년 3월경 SimpleReport 온보딩 프로세스를 보여줍니다. 왼쪽에는 사용자가 수행하는 행동이 보입니다. 이러한 상호작용을 ‘프론트스테이지’라고 하며, 뒤에서 더 자세히 설명하겠습니다. 백스테이지에는 이 과정에서 HHS, USDS, 그리고 지역 공중보건 부서가 수행하는 행동이 나옵니다. 이는 무대 뒤 상호작용, 즉 백스테이지 행동입니다. 온보딩의 첫 단계는 사용자가 SimpleReport.gov에서 요청 양식을 작성하는 것이었습니다. 그러면 USDS가 기관에 계약서를 이메일로 보냈습니다. 계약서에 서명하면 HHS가 사용자에게 줌(Zoom) 약속을 잡을 수 있는 링크를 이메일로 보냈습니다. 사용자가 그 줌 통화에 접속하면 HHS 직원이 기관 관리자(Organization Administrator)의 신원을 확인했습니다. 그 다음 우리 팀이 SimpleReport에 해당 기관을 생성했는데, 이는 접근관리 시스템으로 사용하는 Okta로부터 계정 생성 이메일을 트리거했습니다. 사용자는 이메일의 링크를 따라 SimpleReport 계정을 생성했습니다. 그 시점부터 SimpleReport를 사용해 검사 보고를 시작할 수 있었습니다.

보시다시피, 이는 직원의 수작업 개입을 요구하는 꽤 복잡한 절차였습니다. 새 학년이 다가오면서 가입자가 대거 증가할 것으로 예상되었고, 이 프로세스를 처리하는 HHS와 USDS 팀이 새 학년 준비가 본격화되면서 과부하에 빠질 중대한 위험이 있었습니다. 이 블루프린트는 온보딩의 모든 단계를 우리가 손에 잡히게 파악하도록 도왔고, 현재 프로세스에서 가장 큰 제약이 어디인지 파악하는 데 가이드 역할을 했습니다.

그 제약 중 하나가 바로 신원 확인 절차였습니다. 앞서 말했듯 사용자는 HHS 직원과의 줌 통화를 예약해야 했고, 그 통화에서 기관 관리자의 신원을 확인했습니다. 이에 우리 개발자들은 사용자의 신원을 확인할 대체 메커니즘을 검토했습니다. 우리는 Experian과 협력해 그들의 신원 확인 시스템을 SimpleReport에 통합하기로 했습니다. 이를 통해 사용자는 개인 금융 관련 질문에 답하는 방식으로 신원을 확인할 수 있었고, CDC 직원과 예약된 줌 통화를 할 필요가 없어졌습니다. 가입 처리 시간은 약 2~4주에서 몇 분으로 줄었습니다. 이러한 변경 이후, 시설은 가입한 당일에 SimpleReport로 보고를 시작할 수 있게 되었습니다.

구(舊) 온보딩 프로세스에서는 보통 주당 신규 사용자가 약 30곳 정도였습니다. 새 프로세스를 출시하자 그 숫자는 주당 약 200곳으로 빠르게 뛰었습니다. 6개월 내에 SimpleReport를 사용하는 기관 수는 800% 증가했습니다. 이렇게 직원 측면의 경험(백스테이지)에서 대다수 수작업 개입을 제거함으로써, 우리는 사용자 경험을 크게 개선하고 도입 규모를 확장할 수 있었습니다. 이제 리즈에게 넘겨, 서비스디자인을 위한 툴킷과 프레임워크를 더 자세히 소개하도록 하겠습니다.

LIZ FOX 53:14

고맙습니다, 빅터. 좋아요. 지금부터 저는 툴킷과 프레임워크, 그리고 여러분이 실제로 이것들을 어떻게 할 수 있는지에 대해 이야기하겠습니다. 빅터가 방금 들려준 사례 같은 이야기를 들으면, 저는 늘 매우 고무되지만 동시에 위축되기도 합니다. 저 정도로 복잡하고 임팩트가 큰 일을 내가 과연 감당할 수 있을까 싶기 때문입니다. 그래서 우리는 이런 큰 프로젝트를, 이런 수준의 임팩트를 가진 프로젝트를, 어떻게 쪼개어 접근할 수 있는지 보여 주는 몇 가지 프레임워크를 제공하고자 했습니다. 빅터가 말한 방법론 중 일부를 실제로 어떻게 적용할 수 있을까요? 다음 슬라이드로 넘어가 주세요 — 제가 할 수 있나요? 누군가가 넘겨 주시나요? — 고맙습니다, 슬라이드 요정님.

오늘 하루 중 하나만 기억한다면 이걸 기억해 주시기 바랍니다. 이 그림은 우리 웹사이트(앞서 셰릴이 보여 주었습니다)의 서비스디자인 프레임워크 영역에서 가져온 일러스트레이션입니다.

서비스디자인이 무엇인지 시각화하고 설명할 때 가장 인기가 많은 유형 중 하나입니다(이 특정 도표만을 뜻하는 것은 아닙니다). 빅터의 지하철 이야기로 돌아가 보세요. 빅터는 우리의 오디언스입니다. 그는 무언가를 ‘하는’ 사람으로, A에서 B로 이동하기 위해 서비스를 이용하려고 합니다. 프론트스테이지에는 티켓, 개집표기(턴스타일), 또는 역에서 빅터의 질문에 답할 준비가 되어 있는 실제 직원 등을 떠올릴 수 있습니다. 우리가 흔히 생각하지 못하는 것은 백스테이지입니다 — 빅터가 말한 카운트다운 시계를 작동시키는 모든 센서들일 수도 있습니다. 그 뒤에는 더 많은 ‘비하인드’가 있습니다. 서로 다른 조직의 재무·법무팀 사람들이 있고, 설치 기사들이 센서를 달기 위해 현장에 들어갈 수 있는지를 좌우하는 현장 작업자 스케줄링 도구가 있을 수도 있습니다. 이런 것들이 경험을 바꿉니다. 조직 내부의 여러 부분들, 또는 다른 조직의 요소들이 모여 빅터와 청중이 보게 되는 하나의 경험을 형성합니다.

LIZ FOX 55:21

어떤 문제가 서비스디자인 문제의 좋은 후보인지 궁금하실 수 있습니다. 저는 늘 ‘정말정말 큰 문제’를 찾으라고 말씀드립니다. 문제가 큰 이유는 여러 가지이지만, 우리가 자주 보는 것은 여러분이 서비스하는 고객에 대한 정보나 지식의 부족입니다. 이는 여러 이유로 발생합니다. 조직에 사람들과 접촉할 메커니즘이 없을 수도 있고, 법적 제약으로 인해 접촉이 막혀 있을 수도 있습니다. 또한 커뮤니케이션이 사일로화되어 있을 수도 있습니다. 조직의 한 부서는 사용자에 대해 많이 알지만, 다른 부서는 모르며 서로의 존재조차 모르는 경우입니다. 기술 시스템이 노후화·분절화되어 충분하지 않은 경우도 있습니다. SimpleReport 사례에서 보았듯, 이런 기술 문제는 앞의 두 문제를 더 악화시킵니다. 지식이 있는 다른 사람들의 존재를 모를 뿐 아니라, 설령 알아도 그들에게 접근할 수가 없습니다. 제가 개인적으로 프로젝트 제안을 받을 때 주의 깊게 보는 또 하나는 제가 ‘빙산 버즈워드(glacier buzzwords)’라고 부르는 것입니다. 겉으로 보기에는 무해해 보이지만 그 밑에 거대한 잠재적 기능 장애 덩어리가 숨어 있는 표현들입니다. 제가 가장 좋아하는(?) 것은 ‘디지털 전환’입니다. 종종 ‘리프트 앤드 시프트’라는 표현이 함께 따라오는데, 기존 프로세스를 그냥 들어 올려 다른 플랫폼으로 옮기거나 단순히 디지털로 만드는 것을 말합니다. 뚜껑을 열어보면 서로 얽힌 시스템의 난장판이 함께 손봐야 할 것으로 드러나는 경우가 보통입니다.

이것은 서비스디자인을 고려해야 하는 또 다른 유형의 예시입니다. 화면은 digital.gov의 스크린샷인데, 연방정부에서 고객경험(CX) 관련 의무가 증가하고 있음을 상기시켜 줍니다. 이제 단지 서비스를 제공하는 것뿐 아니라, 왼쪽 열에 있는 모든 것들을 신경 써야 합니다. 여러분은 서비스를 제공하고, 동시에 웹사이트도 운영합니다. 그 웹사이트에 대해 크게 생각하지 않았을 수 있지만 이제는 그 위에서 좋은 고객경험을 보장해야 하는 책임이 생겼습니다. 이런 의무를 어떻게 충족할지 찾는 일은 쉽지 않으며, 서비스디자인과 같은 보다 총체적인 접근이 필요합니다. 다음 슬라이드로 넘어가 주세요.

우리가 앞서 언급한 프레임워크가 바로 이 것입니다. 웹사이트에 올라와 있습니다. 인간중심디자인 다이어그램을 보신 적이 있다면 매우 익숙하실 겁니다. 이 발표를 준비하면서 빅터와 제가 자주 나눈 대화 중 하나는, 서비스디자인과 제품디자인, 인간중심디자인, 사용자경험디자인 사이의 실제 차이가 무엇이냐는 것이었습니다. 어떤 면에서는 이 모두가 비슷합니다. 인간을 제품이나 시스템 설계 과정에 끌어들이려는 접근이라는 점에서 그렇습니다. 하지만 제가 생각하기에 서비스디자인은 제품디자인보다 한 단계 추상화 수준이 높아서 범위가 조금 더 넓습니다. 따라서 제품디자인 프로젝트 경험이 있다면, 프로젝트의 단계는 매우 비슷하게 느껴질 것입니다 — 착수(initiate), 발견(discover), 전략화(strategize), 실험(experiment), 구현(implement) — 저는 잠시 후 각각을 자세히 설명하겠습니다. 잠시 멈춰 채팅을 보니 질문은 아직 없는 것 같습니다. 진행하면서 질문이 떠오르면 자유롭게 남겨 주시고, 저희가 진행하면서 답변드리겠습니다. 좋습니다. 다음으로 가겠습니다.

첫 번째 단계는 ‘착수’입니다. 오늘 늦게 마리가 진행할 워크숍에서 이 단계를 다룰 것입니다. 모두에게 익숙한 킥오프 미팅이라고 보시면 됩니다. 큰 새 프로젝트를 시작할 때 필요한 사람들을 모두 한자리에 모아 무엇을 할지 논의합니다. 서비스디자인 프로젝트이든, 제품디자인 프로젝트를 서비스디자인으로 전환하려는 경우이든, 이 단계는 매우 중요합니다. 이런 프로젝트는 매우 커질 수 있고 범위가 모호할 수 있습니다. 그러므로 성과(outcome)보다는 ‘구체적으로 어떤 문제’에 집중할 것인지 분명히 하는 것이 성공의 기반이 됩니다. 앞서 말씀드렸듯 마리가 이해관계자 매핑 연습을 함께 할 텐데, 이는 서비스디자인에서의 추상화 수준과 범위를 이해하는 데 도움을 줄 것입니다. 단순히 고객에게 판매할 ‘제품’을 만든다고 생각할 때와, 내가 접촉하지 않는 많은 사람들까지 연루되는 ‘경험’을 만든다고 생각할 때, 이해관계자의 범위는 크게 달라집니다. 다음으로 넘어가겠습니다.

빅터의 이야기에는 착수 단계, 특히 ‘집중할 문제를 고르는 법’의 좋은 사례가 있습니다. 코로나가 처음 급격히 확산되기 시작했을 때 정말 무서웠습니다. 모든 것이 대형 화재처럼 느껴졌습니다. 돕고 싶어도 어떤 문제에 집중해야 할지조차 가늠하기 어려웠습니다. SimpleReport 팀이 흥미로웠던 점은, 기존 시스템의 지원이 잘 닿지 않던 영역 — 요양시설 같은 비전통적 검사 현장 — 을 선택했다는 것입니다.

‘발견’ 단계는 제품디자인을 해보셨다면 매우 익숙합니다. 끝이 없는 느낌이 들며, 사실상 끝나지 않습니다. 프로젝트 초기에 알았더라면 좋았을 것들을 계속 발견하게 됩니다. 발견 단계에 사용할 수 있는 방법론은 다양하지만, 목표는 개입하려는 시스템과 사람을 있는 그대로 깊이 이해하는 것입니다. 다음으로 넘어가겠습니다.

서비스디자인 프로젝트에서 가장 유명한 산출물은 서비스 블루프린트입니다. 빅터가 앞서 조금 언급했듯, 서비스디자인을 다른 디자인과 구분하는 핵심은 프론트스테이지/백스테이지라는 개념, 즉 경험하는 사람에게 보이는 것과 보이지 않는 것입니다. 저는 이 일을 할 때 서비스 블루프린트를 ‘연구를 합성(synthesis)하는 틀’로 사용하는 것을 매우 좋아합니다. 누군가와 인터뷰를 하거나 워크숍을 진행한 뒤에는 블루프린트 초안으로 돌아가서 방금 배운 것을 업데이트합니다. 기존에 알던 것과 무엇이 충돌하는지, 아무도 무슨 일이 일어나는지 모르는 곳은 어디인지 표시합니다. 이렇게 하면 제 연구의 방향을 다듬고 일관되게 유지할 수 있으며, 동시에 이해관계자들과 함께 검토할 공통 산출물이 생겨 진행하면서 학습을 공유할 수 있습니다.

[‘전략화(Strategize)’ 슬라이드] 다음으로 해야 할 일은, 해결하려는 문제와 문제 공간을 충분히 이해했다면 ‘어디서부터 해법을 시작할지’를 정하는 것입니다. SimpleReport의 경우, 현실이 빅터와 팀에 큰 도움을 주었습니다. 다음 슬라이드로 넘어가겠습니다.

비전통적 검사 현장에서 새로운 대규모 문제가 다가오고 있었고, 학교 재개를 바라보던 시점에 우리는 이들 비전통적 검사 현장의 새로운 사용자 집단이 SimpleReport에 온보딩되어 실제로 사용할 수 있어야 한다는 것을 알았습니다. 이는 “온보딩 프로세스를 살펴보고 개선하자”라는 보다 구체적인 초점으로 이어졌습니다. 다음으로 넘어가겠습니다.

‘실험’ 단계는 스타트업이나 애자일 소프트웨어 개발을 해보셨다면 매우 익숙합니다. 몇 가지 아이디어를 가장 빠르고 가장 저렴한 방식으로 시험해 보면서, 더 많은 시간을 들일 가치가 있는 것과 그렇지 않은 것을 가려냅니다. 제가 서비스디자인에서 정말 좋아하는 점은, 반드시 기술 시제품을 만들 필요가 없다는 것입니다. 기술과 전혀 관련이 없어도 됩니다. 스카이라이트가 디지털 전환을 다루지만, 기술 문제가 아닌 문제를 발견했을 때 더 낫고 비기술적인 해법을 찾지 못할 이유는 없습니다. “UI 하나 더 디자인하자”에만 머물지 않고 더 큰 도구 상자를 활용해 여러 문제를 해결할 수 있다는 점은 매우 보람 있고 재미있습니다. 다만 실제로 무엇을 테스트할지 결정하는 일은 어려울 수 있습니다. 다음으로 넘어가겠습니다.

이 경우에도 서비스 블루프린트가 매우 유용했습니다. 어디에 큰 문제가 있는지 시각적으로 잘 보여 주기 때문입니다. 온보딩에는 상단의 어두운 파란색으로 ‘관심(Interest)’, ‘접근 권한 받기(Getting access)’, ‘설정(Setup)’의 몇 가지 단계가 나열되어 있습니다. 각 항목은 해당 단계에서 수행되는 활동의 묶음입니다. 여기서 ‘접근 권한 받기’가 매우 큽니다 — 다른 열의 두 배 크기입니다 — 그런데 이 활동은 실제로 그렇게 중요한 행동이 아닙니다. SimpleReport의 핵심 사용자 목표가 아닙니다. 따라서 바로 그 지점이 집중해야 할 영역이라는 명확한 신호였습니다. 다음으로 넘어가겠습니다.

마지막으로 해야 할 일은 ‘구현’입니다. 여기까지 하면 모든 것이 ‘이제는 내리막’처럼 느껴질 수 있습니다. 제안한 해법이 요구하는 변화를 계획하고, 여러분이 개입해야 할 수도 있는 프로세스를 소유한 다른 부서나 사람들과 함께 일해야 합니다. 그리고 무엇보다 — 아니, 최소한 매우 중요하게 — 개선된 서비스를 측정할 지표를 사전에 설정해야 합니다. 다음으로 넘어가겠습니다.

지금 보시는 그래프는 누구나 프레젠테이션의 끝에 보여주고 싶어 하는, 오른쪽 위로 향하는 선입니다. SimpleReport의 온보딩 수치입니다. 온보딩 수치를 추적하는 것은 당연히 온보딩 흐름을 개선하는 데 좋은 지표입니다. 이런 종류의 프로젝트를 많이 수행할수록 추적하는 지표도 늘어나고, 서비스 전반의 분석 포트폴리오가 쌓입니다. 시간이 지날수록 무엇이 잘 작동하고 무엇이 그렇지 않은지, 어디를 다시 서비스디자인 프로젝트로 다뤄야 하는지 더 선명하게 알 수 있습니다.

정리하겠습니다. 단계는 착수, 발견, 전략화, 실험, 구현입니다. 슬라이드를 캡처하실 필요는 없습니다. 모두 웹사이트에 있습니다. 다음 슬라이드는 스크린샷일 것입니다. 보이시죠. 웹사이트의 ‘work’로 가신 다음, 아마 ‘toolkits’로 들어가시면 찾으실 수 있습니다. 좋습니다. 다음으로 저희는 나중에 워크숍을 진행하고, 사례 발표와 패널 토론도 이어집니다. 셰릴이 말했듯, 이들은 기술과의 연계 정도가 서로 다를 것입니다. 모두의 발표를 듣게 되어 매우 기대됩니다. 채팅에 질문이 더 있는지 다시 확인하겠습니다.

Q&A

CHERYL HAMMOND 1:05:51

리즈, 정말 감사합니다. 제가 몇 가지 질문을 전달하겠습니다. 채팅을 처음부터 다시 읽을 필요는 없습니다. 페데리카가 이렇게 물었습니다. 빅터가 일부 답했지만 리즈의 의견도 듣고 싶다고 했습니다. “아까 보여주신 서비스 블루프린트를 만들 때 사용한 활동이나 도구는 무엇입니까? 예를 들어 인터뷰, 설문 등 어떤 방식으로 정보를 수집하셨습니까?”

LIZ FOX 1:06:14

빅터, SimpleReport 사례 — 그 구체적인 사례 — 에 대해 덧붙일 것이 있습니까?

VICTOR ZAPANTA 1:06:19

어떻게 구성했는지에 대해 조금 말씀드리면, 우리는 Mural이라는 도구를 사용했습니다. 채팅에서도 언급했듯, 서비스 블루프린트를 만드는 훌륭한 템플릿이 있습니다. 하지만, 그 작업은 정말로 팀의 집단적 노력의 결과였습니다. 서비스와 모든 구성 요소에 대한 우리 팀의 공유된 이해를 바탕으로 했습니다. 디자인과 리서치, 제품관리, 그리고 우리 서비스에서 무슨 일이 벌어지는지 백엔드를 잘 아는 엔지니어들 사이의 대화가 핵심이었다고 생각합니다.

LIZ FOX 1:06:57

그러니까, 저는 거의 — 죄송합니다, 제가 누군가의 말을 끊은 건가요? 아니면 제 마이크 문제인가요?

CHERYL HAMMOND

리즈, 계속해 주세요.

LIZ FOX

저는 서비스 블루프린트를 ‘대화의 시각화’라고 생각합니다. 이해관계자와 팀과 같은 대화를 거듭하면서 나오는 것이 블루프린트입니다. 누구는 프로세스가 이렇다고 말하지만, 정책 문서에는 저렇다고 쓰여 있고, 또 다른 설치·현장에서는 이렇게 말합니다. 그러면 그것들을 어떻게 정합적으로 맞춰 나갈 것인가가 과제입니다. 연구 방법론으로는 제 경우 대부분 인터뷰였고, 그 다음으로는 자료·문헌 조사(데스크 리서치)를 많이 했습니다. 저는 공군과 일하기 때문에, 웬만한 것에는 누군가가 인용할 수 있는 정책 문서가 늘 존재합니다. 현실에서 그 정책이 얼마나 지켜지는지는 모르는 일이지만, 문서는 정말 많습니다.

CHERYL HAMMOND 1:07:53

좋습니다, 레이첼의 또 다른 질문이 있습니다. 정말 멋진 질문이라고 생각합니다. “업무가 과중할 때 팀이 의도적으로 ‘멈춤’을 갖는 경우가 있었습니까? 빅터의 이야기가 주는 감정적 울림이 매우 컸습니다. 만약 그랬다면, 누가 시작했고 누가 퍼실리테이션했습니까? 업무 시작 전에 디자인 케어 플랜이 마련되어 있었습니까?”

VICTOR ZAPANTA 1:08:21

훌륭한 질문입니다. 솔직히 말씀드리면, 당시 우리는 모두 엄청난 압박을 느끼고 있었습니다. 솔직히 큰 의미의 ‘멈춤’을 많이 갖지는 못했습니다. 우리가 멈춤에 가장 가까웠던 때는 마감이 덜 급하고, 불이 덜 난 기능에 집중했을 때였습니다. 앞서 말씀드렸듯, 2021년 8월까지 제가 공유한 그 기능을 반드시 출시해야 했습니다. 그렇지 않으면 사실상 모든 것이 불탈 상황이었습니다. HHS 직원도, USDS 인력도 그 모든 수작업 개입을 처리할 만큼 충분하지 않았습니다. 그래서 솔직히 말하면, 멈춤에 가장 가까웠던 순간은 주요 출시 이후였고, 그때는 사용자들의 삶의 질을 개선하는 — 하지만 기한 압박이 덜한 — 일들에 집중하곤 했습니다.

CHERYL HAMMOND 1:09:36

빅터, 정말 감사합니다. 자, 다음 질문은 크리티의 질문입니다. “발견 단계에서 서비스 블루프린트를 구성할 때, ‘원래 그렇게 되어 있어야 하는 여정’이나 ‘관리자들이 그렇게 된다고 생각하는 여정’이 있는가 하면, 사람들이 그동안 만들어 낸 온갖 작은 ‘우회로(워크어라운드)’가 있어서 실제로는 다르게 진행되곤 합니다. 이런 우회로를 어떻게 포착하십니까? 또 이를 추가 연구나 조사 기회로 어떻게 프레이밍하십니까?” 그리고 제가 덧붙이면, 때로는 이런 작은 우회로 때문에 사람들이 곤란해지는 경우도 있습니다. 관리자가 와서 “그렇게 하면 안 된다”고 말할 때, 이런 상황을 어떻게 문서화하십니까? 현실 세계에서 블루프린트를 어떻게 전략화하는지 말씀해 주실 수 있습니까?

LIZ FOX 1:10:22

제가 한번 답해 보겠습니다. 사실 저는 사람들이 어떻게든 일을 해내기 위해 만들어 내는 별난 작은 방법들을 찾아내는 것이 제 일에서 가장 좋아하는 부분이라 웃음이 나옵니다. 저는 그런 것들을 발견하는 일이 언제나 매우 흥미롭습니다. 경력 대부분을 엔터프라이즈 소프트웨어에서 보냈기 때문에, 때로는 정말 이상하고 어색한 상황에 놓이기도 합니다. 관리자가 직원들의 업무나 근무 환경을 잘 이해하지 못하는 탓에, 우리가 오히려 직원들을 대신하여 관리자에게 옹호해야 하는 위치에 서게 됩니다. 매우 어색합니다. 그런 역할을 할 수 있는 위치에 있다는 점은 특권이라고 느끼지만, 정말 어려운 일이기도 합니다.

문서를 읽기 쉽게 유지하기 위해 제가 하는 일 중 하나는, 일종의 ‘커트어웨이(cutaway)’를 두는 것입니다. 거대한 서비스 블루프린트가 있고, 이를 보다 보면 — 예를 들어 — 공군과 진행한 어떤 편의 조치(accommodation) 프로젝트에서 아무도 자금 흐름을 이해하지 못한다는 것을 알게 된 적이 있습니다. 그래서 그 부분만 따로 박스로 빼서 소(小) 서비스 블루프린트를 만들어 별도로 다뤘습니다. 또 하나는, 작은 팀과 일할 때는 특히 어렵지만, 그럼에도 불구하고 참여자들의 신원을 가능한 한 익명으로 유지하려 애쓴다는 점입니다. 누가 어떤 말을 했는지 이상의 상세 정보는 제공하지 않으려 합니다. 셰릴이 말씀하신 것처럼, 우리가 정말 흥미로운 우회로를 발견하면 그 사람의 관리자가 가서 혼내는 일이 벌어지곤 했기 때문입니다. 이게 제 긴 답변입니다. 빅터, 더 나은 답변이 있으신가요?

VICTOR ZAPANTA 1:12:17

정확한 말씀입니다. 이어지는 질문도 흥미롭습니다. 공식적으로 허용되지 않은 우회로를 사용하고 있을 수 있는 직원들의 신원을 어떻게 보호하는지에 대한 리즈의 생각이 궁금합니다. 저는 간단히 말씀드리면, 정보에 접근할 필요가 있는 사람들 — 실제 원시 연구 노트를 읽어야 하는 사람들 — 만 접근할 수 있도록 하려고 합니다. 보통은 핵심 제품팀만이 실제 원시 노트에 접근할 수 있어야 합니다. 또 우리는 그 노트를 익명화하기 위해 노력합니다. 노트에는 실제 이름이 들어가면 안 됩니다. 물론 충분한 맥락이 주어지면 개인이 누구인지 유추될 수 있습니다. 그런 경우에는… 네, 리즈의 생각이 궁금합니다.

LIZ FOX 1:13:14

사실 문맥에 따라 다릅니다. 저도 그런 상황을 겪어 봤습니다. 결국 그 어색한 상황 — 우리가 놓이게 되는 그 이상한 위치 — 으로 돌아갑니다. 우리가 팀을 도울 수 있는 유용한 방식 중 하나는 단지 서비스디자인 프로젝트를 수행하는 데 그치지 않고, 팀이 ‘스스로 어떻게 기능하는지’를 더 잘 이해하도록 돕는 것입니다. 외부에서 들어온 컨설턴트나 디자이너의 말을, 내부 팀의 말보다 더 잘 듣는 경우가 있습니다. 그런 경우 우리는 직원들이 겪고 있는 문제를 포착하고, 그것을 증폭해 주고, 정당성을 부여할 수 있습니다. 일종의 옹호자 역할을 할 수 있는 것입니다. 정말 어려운 일입니다. 저는 신원 공개를 요구하는 압박을 받은 적도 있지만, “안 됩니다, 그렇게는 하지 않겠습니다”라고 말해야 했습니다. 더 나은 답이 있으면 좋겠지만, 우리가 떠난 뒤에 그들에게 어떤 일이 벌어질지 늘 조금 걱정이 됩니다.

CHERYL HAMMOND 1:14:20

아주 좋습니다. 채팅에 또 다른 질문이 있습니다. 패니가 이렇게 물었습니다. 먼저 사례들이 정말 흥미롭다고 했고(저도 동의합니다), “프론트스테이지와 백스테이지에서 벌어지는 모든 것을 누가 조율합니까?”

LIZ FOX 1:14:39

답은 “아무도 없습니다”입니다. 제가 배운 것 중 하나는, 어디서나 항상 모든 것이 혼돈이라는 사실입니다. 제가 발견(Discovery) 단계에서 서비스가 어떻게 작동하는지 파악하려 할 때, 그걸 명확히 아는 사람이 다른 데에서 이미 존재하는 경우를 거의 보지 못했습니다. 오히려 우리가 조직이 ‘어떻게 기능하는지’를 이해하도록 돕는 일이, 때로는 그 조직 역사상 처음으로 이루어지는 가치 있는 기여가 되곤 합니다. 보통은 프론트스테이지와 백스테이지를 이미 조율하고 있는 ‘누군가’를 무대 뒤에서 발견하곤 하지 않습니다. 제 프로젝트는 대체로 “어떤 기술(테크) 조각을 디자인해 달라”는 요청으로 시작되고, 저는 그 기술 조각이 본래 목적을 제대로 달성할 수 있도록 서비스디자인을 빈틈에 억지로 끼워 넣는 편입니다. 그래서 정책 같은 부분은 많이 건드리지 못하곤 합니다. 빅터, 당신은 경험 범위가 더 넓으니 이 질문에 더 나은 답이 있을까요?

VICTOR ZAPANTA 1:15:39

특별히 더할 말씀은 없습니다만, 제가 공유한 예에서는, 그 과정 — 제가 공유한 서비스 블루프린트 — 이 자연스럽게 진화한 것이었습니다. 우리는 일종의 ‘역공학’을 했습니다. 이미 상호연결된 시스템이 구축된 다음에 “아, 이건 서비스구나”라고 인식하게 된 것입니다. 결국 우리가 도달한 지점은, 개발자들이 필요한 수준의 조율을 효과적으로 자동화한 상태였습니다. 물론 이는 제품팀 전체의 협업을 통해 이루어졌습니다.

CHERYL HAMMOND 1:16:34

이번 세션에 약간의 시간이 더 남아 있습니다. 질문을 더 받을 수 있습니다. 줌의 손들기 기능을 사용해 음성으로 질문하셔도 되고, 계속해서 채팅에 남겨 주셔도 좋습니다.

또 한 가지 알려 드리자면, 곧 있을 패널 세션에서 발언하실 테일러가 지금 이 방에 함께하고 계십니다. 테일러는 서비스 블루프린트에서 사람들의 신원을 보호해야 했던 경험이 있다고 밝혔고, 그 경험을 여러분과 기꺼이 공유하실 예정입니다. 기대해 주시기 바랍니다.

힐러리, 손을 드셨네요. 음소거를 해제하고 질문해 주셔도 됩니다.

HILARY SEDOVIC 1:17:16

여러분, 오늘 우리를 초대해 주셔서 감사합니다. 여기 오게 되어 기쁩니다. 저는 앞서 레이첼이 제기한 ‘멈춤’에 관한 질문을 이어가고 싶습니다. 우리는 모두 위기와 트라우마의 한가운데를 지나고 있었고, 여러분은 그 한가운데에서 지원 업무를 수행하고 있었습니다. 여러분이 “멈출 여지가 없었다”고 말씀하셨지만, 돌아보면, 적절한 지원과 자원이 주어졌을 때 무엇이 있었으면 좋았는지, 무엇을 다르게 했으면 좋았다고 생각하시는지 궁금합니다.

VICTOR ZAPANTA 1:17:54

아, 정말 훌륭한 질문입니다. 팀 내에 번아웃이 꽤 있었습니다. 많은 분들이 들락날락했고, 말씀하신 바로 그 주제 — 우리가 삶 속에서 경험하던 일을 업무로도 다루었다는 사실 — 에 대해 대화를 나누었습니다. 우리 팀은 정서적으로 매우 안전한 팀이었습니다. 그러나 그러한 압박이 개인에게 얼마나 영향을 미치고 있는지에 대해서는, 우리가 스스로를 밖으로 드러내는 데 충분하지 못했다고 생각합니다. 프로젝트 초기에 특히 훌륭한 분들이 함께하셨고, 시간이 지나며 떠나셨습니다. 때로는 스트레스 때문이었을 수도 있고, 때로는 단순히 다음 도전을 준비하셨기 때문일 수도 있습니다. 제게는, 이것을 돕는 가장 큰 방법이자 우리가 했어야 했던 일은, 팬데믹 속에서 일하고 팬데믹을 경험하는 우리의 경험에 대해 더 적극적으로 개방적인 태도를 가지는 것이었다고 생각합니다.

HILARY SEDOVIC 1:19:14

리즈, 덧붙일 말씀이 있습니까? 그리고 빅터, 감사합니다.

LIZ FOX 1:19:21

제 경험도 빅터와 매우 비슷했습니다. 전 세계적 재난 속에서 감정적으로 강도 높은 프로젝트를 수행할 때, 언제 거리를 두어야 하는지 스스로 알아차릴 만큼 충분히 분리하는 것이 정말 어렵습니다. 더 나은 답을 드리지 못해 아쉽지만, 업계 전체가 이 문제에 대해 더 잘해야 한다고 생각합니다. 다음에 정말 강도 높은 일을 할 때 특히 유용하겠다 싶은 것은, 납기를 솔직하게 조금 더 여유 있게 잡는 것입니다. 디자이너들은 일에 열정이 있을수록 “내일까지 할 수 있다”, “금방 끝난다”, “어렵지 않다”고 말하는 경향이 있습니다. 그러고는 회사가 주최하는 서비스디자인 컨퍼런스에서 발표하겠다고 자원하는 등, 여러 가지를 또 얹습니다. 세상이 불타는 듯한 시기에, 늘 데드라인에 쫓기는 느낌이 들지 않도록, 생각할 여백을 스스로에게 주는 것이 좋겠다고 봅니다.

HILARY SEDOVIC 1:20:32

답변 감사드립니다.

VICTOR ZAPANTA 1:20:36

마지막으로 한 가지만 덧붙이겠습니다. 제 머릿속에 계속 떠오르는 공통의 단어는 ‘그레이스(관용)’입니다. 우리 자신에게, 그리고 팀 동료들에게 관용을 베푸는 일입니다.

CHERYL HAMMOND 1:20:47

정말 좋습니다, 빅터. 감사합니다. 에밀리, 손을 드신 것을 보았습니다. 음소거를 해제하고 질문하셔도 됩니다. 감사합니다.

EMILY LIPPOLIS 1:20:54

좋습니다. 이렇게 이 일을 사랑하는 다른 ‘덕후’들을 보게 되어 정말 멋집니다. 팬데믹 같은 초재난 상황이 아닐 때, 즉 ‘코비드가 아닐 때’는 회사나 기관이 언제 서비스디자이너에게 도움을 요청합니까? 보통 어떤 계기가 “문제가 있으니 당신들이 필요합니다”로 이어집니까?

LIZ FOX 1:21:22

제가 곧 진행할 몇몇 프로젝트는 훨씬 더 실무적(프랙티컬)인 일에서 시작해 이해관계자와 관계를 쌓은 다음, 그 이해관계자가 더 크고 ‘제대로 된’ 서비스디자인 프로젝트를 제게 맡기고자 하는 경우에서 나왔습니다. 공군과 진행 중인 건이 하나 있는데, 그 시작은 그들의 앱에 대한 기본적인 크리틱이었습니다. 팀과 더 자주 함께 일하고, 여러분에게는 그리 흥미롭지 않을 수 있지만 그들에게 매우 도움이 되는 일을 통해 가치를 보여줄수록 신뢰와 관계가 쌓입니다. 또 채팅에서 누룰(이름을 제가 잘못 읽었을 수도 있는데 죄송합니다)이라는 분이 말씀하셨듯, 이런 경우가 매우 흔합니다. 본질적으로는 ‘기술 요소를 포함한 서비스디자인 프로젝트’로 다뤄야 할 큰 프로젝트가 있지만, 조직이 확보한 예산은 기술 쪽 — 예를 들어 새 티켓팅 시스템 구매 — 에만 묶여 있는 경우입니다. 그래서 저는 아무도 요청하지 않았더라도 서비스디자인을 슬쩍 끼워 넣고, “원래 디자인 프로세스가 이렇게 돌아갑니다, 무슨 말씀이세요”라는 듯 자연스럽게 진행해 봅니다. 누군가 제지하기 전까지 어디까지 갈 수 있는지 시도해 보는 것이죠. 빅터, 더 나은 답변이 있습니까?

VICTOR ZAPANTA 1:22:45

아닙니다. 저는 전적으로 공감합니다. 사람들이 자신들에게 ‘서비스디자인 문제’가 있다는 사실을 이해하는 경우는 매우 드뭅니다. 그래서 저는 서비스디자인을 인간중심디자인의 하위 집합으로 접근한다고 말씀드렸습니다. 제 관점에서 서비스디자인을 전통적 디자인 접근과 구분 짓는 핵심은 ‘직원(백스테이지) 경험’에 대한 초점입니다. 대개 사람들은 자신의 조직이 완벽히 효율적으로 작동한다고 생각합니다. 제가 보기에는, 의뢰인이 “우리는 서비스디자인 문제가 있습니다”라고 말하는 경우는 드뭅니다. 최선의 경우, 리즈가 암시한 대로, “우리는 기술 문제가 있습니다”라고 말하곤 합니다. 그러면 우리는 “그건 사실 디자인 문제이고, 더 정확히는 서비스디자인 문제입니다”라고 설명하게 됩니다.

EMILY LIPPOLIS 1:23:44

감사합니다.

CHERYL HAMMOND 1:23:48

아주 좋습니다. 시간이 조금 더 남았으니 마지막 질문을 한 개 더 받을 수 있을 것 같습니다. 없으시다면, 빅터와 리즈에게 마지막으로 한 말씀과, 여러분이 어디서부터 시작할 수 있을지에 대한 제안을 부탁드리고 싶습니다 — 아, 그 전에 수잔에게 질문이 있다고 합니다. 감사합니다, 수잔.

SUZANNE GRAY 1:24:10

안녕하세요, 감사합니다. 기술 문제와 서비스디자인 문제에 대한 이야기가 정말 마음에 듭니다. 내부 팀을 이런 방식으로 일하게 ‘설득’하는 방법이 무엇인지 궁금합니다. 우리는 서비스 블루프린트가 ‘대화의 시각화’라는 이야기를 했고, 그 표현이 매우 좋았습니다. 하지만 제 팀을 설득해 블루프린트를 만들고, 이런 집단적 이해를 쌓는 데 시간을 쓰게 하는 일이 쉽지 않습니다. “그냥 이야기하면서 문제를 풀자, 현장에서 해결하자”라는 식입니다. 회사 내부에서 이런 방식을 채택하도록 사람들을 설득할 요령이 있을까요?

LIZ FOX 1:24:59

정말 좋은 질문입니다. 제 답이 여러분이 그대로 따를 만한 것은 아닐 수 있지만, 솔직히 말씀드리겠습니다. 저는 그냥 시작합니다. 거의 허락을 구하지 않습니다. 그러다 보니 “리즈는 복잡한 플로차트를 사랑한다 — 플로차트의 그녀다 — 그리고 사람들을 붙잡아 한 시간 동안 플로차트를 보며 이야기하게 만든다”는 평판을 얻게 되었습니다. 제가 하는 일은 종종 공군의 기술 인프라 같은, 정말 백엔드스러운 ‘덕후’ 영역이 됩니다. 저는 엔지니어들이 플로차트 이야기를 좋아하고, 여러분과 함께 끝장토론(해부)하기를 원한다는 걸 발견했습니다. 그러니 꼭 표준 서비스 블루프린트일 필요는 없습니다. 여러분이 말하려는 것을 시각화하고 문서화할 방법 — 플로차트든 간트 차트든 무엇이든 — 을 찾아서, 여러분의 이해관계자와 팀이 ‘좋아하는 방식’으로 보여 주는 것이 좋습니다. 그들이 있는 자리에서 그들을 만나는 것입니다. 그리고 다시 말하지만, 허락을 구하지 말고 하려는 일을 하십시오. “이제 우리는 이렇게 합니다”라고 알려 주세요.

SUZANNE GRAY

좋습니다, 감사합니다.

CHERYL HAMMOND 1:26:17

아주 좋습니다. 채팅에 또 다른 질문이 들어왔습니다. 일자는 이렇게 묻습니다. “주니어(엔트리 레벨) 서비스디자이너가 정부 조직에 합류하려 할 때, 빠르게 적용할 수 있는 조언이 있습니까?”

VICTOR ZAPANTA 1:26:32

가장 ‘직설적인’ 조언부터 드리겠습니다. 정부 이력서를 숙지하십시오. 정부 이력서는 일반 이력서와 매우 다릅니다. 한 페이지일 필요도 없습니다. 구인 공고에서 찾은 키워드를 모두 사용하십시오. 가능한 한 많은 키워드를 넣으십시오. CFPB에는 좋은 정부 이력서를 만드는 훌륭한 가이드가 있습니다. 초반 몇 라운드는 사실상 키워드 매칭으로 진행되는 경우가 많다고 생각합니다. 최소한 그 관문은 통과해야 합니다. 다시 말하지만, 가장 직설적인 조언이지만, 개인적으로는 여기서부터 시작하길 권합니다.

LIZ FOX 1:27:16

이 말이 그다지 유용하게 들리지 않을 수 있지만, 진짜로 최고의 조언입니다. 정부 채용은 산업계와 비교해 매우 까다롭고 특이합니다. 저는 예전에 캘리포니아에 살 때 정부 일자리에 여러 번 지원했지만, 정말 터무니없는 이유들로 계속 탈락했습니다. 그래서 네트워킹을 강력히 권합니다. 오늘 같은 행사, Code for America 같은 곳에서, 여러분이 일하고 싶은 기관 내부 사람을 만날 수 있는 기회를 잡으십시오. 그들은 지원서가 탈락하지 않도록 하는 ‘비결’이 어디에 있는지 이해하도록 돕는 데 큰 자산이 되어 줄 것입니다.

CHERYL HAMMOND 1:28:02

훌륭합니다. 좋습니다, 이제 여기서 마무리하겠습니다. 정각이 다 되어 가므로 모두가 제때 휴식하실 수 있도록 하겠습니다. 계속 대화를 나누고 싶은 분들을 위해 선택적 브레이크아웃 룸을 몇 개 열겠습니다. 커리어 대화를 위한 방 하나, 일반 네트워킹을 위한 방 하나를 만들었습니다. 브레이크아웃에서 다루고 싶은 주제가 있다면 알려 주시면 방을 추가로 만들겠습니다. 전부 선택 사항입니다. 들어가고 싶은 방을 선택하셔도 되고, 당연히 이 방에 남아 계셔도 됩니다. 카메라는 끄고 음소거로 하신 뒤 각자 할 일을 하셔도 좋습니다. 반려견에게 밥을 주셔도 됩니다.

이 시간을 빌려 빅터와 리즈의 발표에 깊이 감사드립니다. 두 분 모두 오늘 이후에도 여러분이 연락하실 수 있습니다.

간단히 상기 드리자면, 모든 세션은 녹화 중이며, 행사 후 스카이라이트 유튜브 채널에 게시될 예정입니다. 지금 팔로우하시면 영상이 올라갈 때 알림을 받으실 수 있습니다. 오늘 모든 세션의 슬라이드와 자료는 지금 바로 구글 드라이브에서 이용하실 수 있습니다. 해당 링크들은 하루 종일 채팅에 공유되어 왔으며, 앞으로도 계속 공유하겠습니다.

이제 휴식에 들어가겠습니다. 15분을 쉬겠습니다. 정각 15분 후에 돌아오겠습니다. 잠시만 기다려 주세요, 다음 순서를 보실 수 있도록 아젠다를 띄우겠습니다. 지금은 휴식 시간입니다. 이후 정각 15분 후에는 스카이라이트와 파트너들이 함께하는 패널 토론이 있습니다. 오늘 오전 내내 테일러가 채팅에서 앞으로 다룰 내용을 미리 보여 주었고, 그 질문과 대화를 패널로 이어갈 예정입니다. 그때 뵙기를 바랍니다. 15분 휴식을 즐기십시오. 지금 선택적 브레이크아웃 룸을 열겠습니다.