코로나가 한창이던 2020년의 어느 날. 늘 그렇듯 평화롭게 뉴스를 보여 어지러운 세계정세를 걱정하던 서점군에게 고객님의 전화가 걸려옵니다.
고객님 : 저희가요 시설에 방문할 때 코로나 설문지를 받고 있는데 이걸 모바일로 만들었으면 좋겠어요!
서점군 : 네~
코로나 설문지라니? 음? 그게 뭐지? 뭔 설문을 받는다는 거야?
오늘은 서점군 앞에 배달된 A4 1장짜리 코로나 설문지를 모바일 웹페이지로 만드는 여정을 함께 하며 오프라인 문서를 어떻게 온라인으로 전환하는지, 모바일 웹페이지는 어떻게 만드는지 맛보기로 살짝만 알아볼까 합니다.
제가 클라이언트(고객님)께 전달받은 코로나 설문지는 아래와 같습니다. (예제)
우리는 이제 위 이미지를 모바일 설문지로 바꿀 겁니다.
작업에 들어가기 앞서 늘 그렇듯 작업 의도를 생각해봐야겠죠. 왜 수기로 받던 설문지를 모바일로 받으려는 걸까?
① 방문객이 많아 대기줄이 길어져 고객의 불만이 있음
② 수기로 접수받던 정보를 전산화하기 위해 (문서 관리의 어려움)
방문객이 많지 않은 시설인 경우 (100명 내외) 수기로 문서를 관리하는 것이 비용이나 관리면에서 온라인보다 효율적입니다. 예를 들면 병원이나 소규모 식당 같은 경우가 그렇죠. 방문객이 100명을 넘어가면서부터는 비용이나 효율성 측면에서 온라인 전환의 이점이 생기게 됩니다. 단순하게 생각만 해도 하루에 100명씩 방문객 설문지를 받으면 한 달만 지나도 3000장의 방문객 설문지가 쌓이게 될 테니까요. 그래서 코로나 설문지를 모바일로 전환하겠다는 시설은 최소 하루 100명 이상의 사람들이 방문하는 시설이고 방문객이 몰리는 시간대는 고객의 대기줄이 길어져 고객 불만이 접수되고 있다 정도를 유추할 수 있습니다.
또한 수기로 설문지를 받게 되면 전산화의 문제가 생깁니다. 확진자가 시설을 방문했을 경우 역학조사를 위해 방문객 정보를 질병관리청에 전달해야 하는데 설문지 100장을 전달할 순 없겠죠? 엑셀이든 워드 문서든 방문객명, 연락처가 담긴 주요 정보만 전달해야 하는데 이건 수기로 받은 문서들을 엑셀 대장에 입력해야 하는 전담 인력이 필요합니다. 이걸 모바일로 전환하면 나중에 문제가 발생했을 때 방문객 데이터를 뽑기도 용이하고 추후 수집한 데이터 파기 시에도 간단하게 처리할 수 있습니다.
의도를 파악했다면 구축 목표도 정의할 수 있습니다.
① 방문객의 불편을 최소화하기 위해 입력항목은 최대한 적고 간단하게 설계한다.
② 데이터 전산화 및 관리가 용이하도록 설계한다.
구축 목표까지 정의했으니 이제부터 진짜 하나하나씩 만들어볼 겁니다.
제일 먼저 만들어볼 것은 설문지 제일 상단의 타이틀과 개요 내용 부분입니다.
타이틀 부분을 만들 때는 중요한 포인트가 하나 있습니다. 타이틀 영역에서 기관 또는 브랜드의 아이덴티티를 노출해야 한다는 거죠. 기존에 웹 또는 모바일 사이트가 있는 시설인 경우 사이트와 내방객 설문 지간의 연속성 있는 브랜드 경험(웹 또는 모바일 사이트에서 내방객 설문지로 이동했을 때 일관성을 느낄 수 있도록)을 위해 내방객 설문지 디자인에 사이트의 디자인을 어느 정도 녹여줘야 합니다. 만약 사이트가 없는 기관이나 시설인 경우 로고의 포인트 컬러를 활용해서 페이지를 딱 봤을 때 'OO시설의 설문지구나'라는 것을 인지시켜줄 수 있을 정도면 됩니다.
그런데 왜 하필 타이틀 부분에 브랜드 아이덴티티를 노출해야 되냐? 다른 부분은 텍스트 입력이나 테이블 구조라 디자인의 포인트를 심거나 자율성을 부여할 수 있는 영역이 거의 없습니다. 타이틀 부분이 유일하죠. 또한 페이지를 처음 접근했을 때 처음 사용자가 보게 되는 부분이 상단 타이틀 영역이니 여기에 브랜드 아이덴티티를 노출한다면 고객이 해당 브랜드 페이지임을 쉽게 인지할 수 있게 됩니다.
내방객 설문지는 별도 페이지이므로 일반적인 모바일 사이트처럼 메뉴는 넣지 않고 로고와 타이틀만 노출합니다. 브랜드 아이덴티티를 표현하기 위해 좌측에 로고나 CI를 넣고 배경은 포인트 컬러를 사용합니다. 이 구성이 별도 모바일 페이지 타이틀의 정석적인 구성입니다. CI를 사용하느냐 로고를 사용하느냐의 기준은 보유하고 있는 로고의 원본 이미지를 보면 알 수 있습니다. 가로형 로고가 있는 시설이면 로고를 전체 사용해도 무방하고 가로형 로고가 없는 시설이면 CI만 노출하고 시설명은 텍스트로 적어주시면 됩니다. 유의해야 할 점은 가로형 로고가 있더라도 로고와 타이틀이 어울리지 않을 수 있으니 머릿속으로 시뮬레이션을 해보고 괜찮겠다 싶으면 로고를 전체 사용하고 어색하다 싶으면 CI만 사용하면 됩니다.
국립현대미술관과 국립중앙박물관 로고를 사용해서 만든 예제입니다. 국립중앙박물관처럼 흰색 로고가 있다면 배경색에 포인트 컬러를 사용해서 다른 스타일로 만들어볼 수도 있습니다.
개요 내용 부분은 영역 구분을 위해 박스와 그레이로 배경 컬러를 살짝 깔아줄 겁니다. 내용이 길면 스크롤을 넣는다던가 접었다 펼치는 형식으로도 가능한데 (회원가입 시 약관처럼) 이건 내용도 길지 않고 중요하기 때문에 전문을 다 넣기로 합니다.
이렇게 상단과 개요 부분이 완성되었습니다.
개요 영역을 만들었으니 다음은 방문자의 개인정보 입력 영역을 만들 차례입니다. 개인정보 입력 영역을 만들기 앞서 우선적으로 고려하거나 확인해봐야 할 3가지 중요한 포인트가 있습니다.
① 모바일 사전 설문지를 어떤 경로로 접근하는가?
② 동행자 정보는 어떻게 처리할 것인가?
③ 모바일로 사전 설문을 하지 않은 방문객은 오프라인에서 어떻게 처리할 것인가?
방문자들은 모바일 사전 설문지 웹페이지를 어떤 경로로 접근할까요?
① 시설에서 발송한 MMS 메시지의 링크를 통해
② 시설 홈페이지에 게시된 링크를 통해
③ 현장에 비치되어 있는 QR 코드를 통해
시설의 이용 유형에 따라 접근 방식이 달라질 수 있고 이후 프로세스에도 영향을 줄 수 있습니다. 온라인에서 사전예약 후 이용이 가능한 시설 (극장, 박물관, 호텔 등) 은 예약 시 입력한 휴대폰 번호로 MMS 메시지를 발송해 메시지의 링크를 통해 모바일 사전 설문지에 접근할 수 있습니다. 이 경우에는 예약 시 입력한 고객정보를 연동해서 개인정보를 따로 입력하지 않지 않게 구현하는 것도 가능합니다. 현장에 비치되어 있는 QR 코드를 통해 접근할 경우 고객정보를 알 수 없는 상태이기 때문에 고객정보는 무조건 수동으로 입력 가능하도록 개발해야 합니다. 이렇게 접근 방식에 따라 개발 방식이나 범위가 달라지기 때문에 기획자는 사전에 이러한 사항을 충분히 확인해야 합니다.
이 시설이 혼자 이용하는 시설 인가 2명 이상의 사람이 이용할 가능성이 높은 시설 인가에 따라 동행자 정보의 입력방식도 고려해봐야 합니다. 사전예약 후 시설 이용이 가능한 시설의 경우 구분은 아래와 같습니다.
① 동행자 정보 무조건 입력 : 비행기
② 강제사항이 아님 : 호텔
③ 입력하지 않아도 됨 : 극장
①번 같은 경우 기입력된 동행자 정보가 있으므로 동행자 정보도 연동해서 가져올 수 있습니다. ②③번 같은 경우는 입력 시 동행자 정보를 추가로 입력할 수 있도록 동행자 정보 입력 기능을 지원해야겠죠?
현장에서 예약이 가능한 시설은 동행자가 있을 경우 고객 편의성에 대해 조금 고민해볼 필요가 있습니다.
① 1명이 사전 설문지 작성 시 동행인 정보까지 입력
② 각자 사전 설문지 작성
②번의 경우 고객 입장에서 상당히 번거로운 상황이 됩니다. 사전 설문지에 입력해야 하는 항목이 생각보다 꽤 많기 때문이죠. 많은 시설들이 네이버나 카카오의 QR 코드를 이용해서 간단하게 본인인증을 하고 입장할 수 있는데 고객의 개인정보를 노출해가면서 직접 입력한다는 건 개인정보 노출 측면이나 고객의 편의성 면에서 고객에게 상당하게 불쾌감을 유발할 수 있는 측면이 있습니다. 사전 설문지를 무조건 받아야 하는 합당한 사유가 있지 않다면 사전 설문은 네이버와 카카오의 QR코드를 이용해 대체하는 것이 좋습니다.
모바일로 사전 설문을 하지 않은 방문객이 시설 방문 시 어떻게 처리해야 할까요?
① A4 용지에 직접 사전 설문을 받는다.
② 모바일 사전 설문 페이지를 안내하고 현장에서 입력을 유도한다.
①번처럼 직접 사전 설문을 받는 경우 관리자 페이지에 수기로 입력받은 정보를 입력할 수 있는 입력 기능을 만들어줘야 할 수 있습니다. 입력 기능을 만들지 않는다면 수기로 입력받은 용지들을 별도로 보관해야 하는데 이러면 사전 설문 기능을 만든 의미가 퇴색되거든요. ②번처럼 현장에서 모바일 페이지를 접속해서 입력을 유도할 경우 사용자의 클레임이 우려되나 업무 프로세스는 훨씬 깔끔해질 겁니다.
3가지 고려사항을 종합하면 아래와 같습니다.
자 이제 한 단계씩 예약자 정보 입력 화면을 만들어볼 겁니다.
먼저 레이아웃부터 시작하죠.
레이아웃은 크게 테이블 구성/2행 구성, 2개 형태로 구분할 수 있습니다.
Type A처럼 기본 테이블에 선이 있냐, 배경색이 있냐 조합으로 다양한 베리에이션을 만들 수도 있고 Type B처럼 한 줄에 데이터 하나로 구성할 수도 있습니다. 테이블 or 2행 구성 중 어떤 레이아웃으로 할 것인지는 일반적으로는 데이터의 길이로 판단합니다. 데이터의 길이가 제한적이고 테이블 구성으로도 큰 문제가 없다면 테이블 구성으로 하는 것이 좋고 데이터 길이가 길어 영역을 넘어갈 경우는 Type B 구조로 만드는 것이 좋습니다. 예를 들어볼까요.
좌측의 예처럼 예약자명, 연락처, 방문(예정) 일시는 데이터 길이가 고정되어 있는 값입니다. 예약자명은 3~5자, 연락처는 숫자 11자리, 방문 예정일시는 년. 월. 일 시가 길이가 고정되어 있는 값이죠. 예약자 명의 경우 변수가 있을 수 있으나 (외국인 예약 시) 테이블 구조 입력에서도 충분히 커버 가능하다고 판단됩니다. (영문 기준으로 최대 15자까지 입력 가능)
우측 예처럼 예약자명, 연락처, 방문일시는 길이가 고정된 값이라고 볼 수 있으나 주소는 데이터 길이 자체도 길고 길이도 가늠하기 어렵습니다. 요즘에는 아파트 이름이 긴 경우가 많아 (예를 들면 동탄시범다은마을월드메르디앙반도유보라아파트 / 21자) 테이블 구조에서는 긴 텍스트 길이를 수용하기가 어렵습니다. 그래서 텍스트 박스 영역보다 데이터 길이가 길거나 예측이 어려울 경우 테이블 구조의 A 보다는 B 구조가 적합합니다.
다시 타입으로 돌아가서 어떤 타입을 사용해야 할지 결정해야 합니다.
A 타입과 B 타입은 각자 장단점이 있습니다.
테이블 구조인 A 타입은 B 타입에 비해 세로 길이가 짧아 불필요한 스크롤을 줄일 수 있습니다. 모바일 환경에는 사용자가 세로 스크롤에 대한 부담이 적은 편이나 그래도 불필요한 스크롤은 최대한 배제하는 것이 좋지 않을까 하는 것이 개인적인 생각입니다.
입력 항목 간격은 테이블 구조인 A 타입이 촘촘하고 B 타입은 조금 여유 있는 편입니다. (이미지 빨간 화살표) 입력 항목 간격은 사용자의 터치 미스를 유발할 가능성이 있느냐로 판단하는 것이 좋습니다. 여백이 여유 있다면 터치 미스를 유발할 확률이 줄어들 테니까요. 마지막으로 여백은 데이터를 다 입력했을 때 여백이 얼마나 남느냐를 판단합니다.(파랑 빗금 박스) A 타입에 비해 B 타입이 여백이 2배 이상 많이 남는 것을 확인할 수 있습니다.
종합하면
- A 타입 : 세로 길이 짧음, 간격/여백 좁음
- B 타입 : 세로 길이 김, 간격/여백 넓음
기획자에 따라 A 타입을 선호하는 사람도 있고 B 타입을 선호하는 사람도 있습니다.
여기서는 A타입을 사용하기로 합니다. 이유는
데이터 길이가 고정되어 있음
세로 스크롤을 늘리고 싶지 않음
터치 미스를 유발할 정도의 간격은 아님
여백이 많으면 휑해 보임
이 4가지가 A 타입을 사용하는 이유입니다.
정답은 없습니다. B 타입을 사용해서 만들어도 되지만 저는 A 타입이 더 적합하다고 판단되어 A 타입을 사용하기로 합니다. 기획을 할 때는 논리를 설명하는 것이 중요합니다. 'OO에서 그렇게 되어 있어서 만들었어요'가 아닌 나는 이런 이런 이유 때문에 이 레이아웃으로 만들었다고 작업자에게 사유를 설명할 수 있어야 합니다.
레이아웃이 결정되었으면 앞서 언급되었던 3가지 포인트를 하나씩 해결해보기로 합니다.
일단 1번) 접근 경로부터 UI에 녹여봅니다.
MMS에 삽입되어 있는 링크를 사용할 경우
① MMS를 발송하기 위해서는 사용자 개인정보가 필요하다.
② 사용자 예약 정보를 가지고 있다.
라는 가정에서 출발합니다. 그럼 예약자명과 연락처는 입력하지 않고 예약 시 입력했던 정보를 쿼리로 연동해서 가져올 수 있습니다. 좌측의 MMS 형태처럼요.
페이지에 직접 접속하거나 QR코드를 이용해 접속하는 경우는 사용자 개인정보를 모른다는 가정입니다. 이럴 때는 예약자명과 연락처를 직접 입력해줘야 합니다. 위 이미지의 우측 형태처럼요.
다음은 2번) 동행자가 있을 경우 동행자 정보 입력입니다.
동행은 추가 버튼은 위 이미지처럼 하단이나 상단에 배치할 수 있습니다.
여기서 문제! 동행인 추가 버튼은 하단에 배치하는 것이 맞을까요? 상단에 배치하는 것이 맞을까요?
사용자의 이용 행태를 잘 생각해보면 답을 알 수 있습니다. 버튼을 하단에 두면 사용자가 정보를 입력하면서 자연스럽게 동행인 추가 버튼 위치로 도달하는 형태가 됩니다. 반면 버튼을 상단에 두면 콘텐츠를 다 입력하고 포커스가 위쪽으로 이동하는 다소 부자연스러운 형태가 됩니다. 동행인이 1명이라면 먼저 동행인 추가 버튼을 누르고 정보를 입력하는 방법도 있지만 2명 3명이 되면 1명 입력 > 동행인 추가 버튼 클릭 > 1명 입력 > 동행인 추가 버튼 클릭 형태로 부자연스러운 이동동선이 이어지게 됩니다. 그래서 물 흐르듯이 자연스러운 흐름을 유지하려면 버튼은 하단에 두는 것이 좋습니다.
이렇게 예약자 정보 입력 영역까지 완성되었습니다.
다시 한번 강조하지만 이 UI가 정답은 아닙니다. 기획에는 정답이 없으며 데이터나 조직의 환경, 업무 프로세스에 따라 UI는 달라질 수 있음을 알려드립니다. 위 예는 그냥 제가 적합하다고 판단한 예제일 뿐입니다.
이제 설문 내용을 체크하는 확인사항 영역입니다. 확인사항 영역은 두 가지 형태로 만들 수 있습니다.
좌측 단일 체크형처럼 이용약관 형태로 반드시 체크해야 하는 형태로 만들 수도 있고 우측 Y/N 선택형처럼 Y 또는 N 하나를 선택하는 형태로 만들 수도 있습니다. 어떤 형태를 사용할 것이냐 선택의 기준은 '유효성 체크'입니다. 특정 옵션을 선택해야 넘어가는 경우(모두 있음 또는 모두 없음을 선택해야 다음 단계로 이동)는 단일 체크형을 사용하는 것이 좋고 항목에 대한 조사가 목적이라면 (있음 없음 중 어떤 것을 선택해도 무방) Y/N 선택형 구조를 사용하면 됩니다.
본 확인사항 설문지는 모두 없음을 체크해야 다음 단계로 이동하기 때문에 여기서는 단일 체크형 레이아웃을 사용합니다.
이렇게 확인사항 체크 영역까지 완성했습니다.
마지막으로 서명 및 제출 영역입니다. 서명은 간단하니까 제작 과정 없이 그냥 심플하게 만들어보겠습니다.
저는 설문지의 느낌을 살리기 위해 서명 부분은 계약서와 유사한 스타일로 만들었습니다.
이렇게 오늘은 코로나 방문객을 위한 모바일 설문지를 만들어보았습니다.
어때요. 여러분 참~ 쉽죠?