First Meeting
그림톡 만들기 2편: 결과 화면을 ‘정보 화면’에서 ‘첫 만남 장면’으로 바꾸기
시작하며
그림톡을 만들면서 가장 오래 붙잡고 있었던 화면은 아마도 결과 화면이었다.
처음엔 이 화면이 꽤 그럴듯해 보였다. 이름도 있고, 정체도 있고, 성격도 있고, 첫 인사도 있고, 질문도 있고, 실제 응답도 있었다. 언뜻 보면 친절해 보였다.
그런데 계속 보다 보니 이상한 느낌이 남았다.
예쁘게 정리돼 있긴 한데, 친구를 만난 느낌보다 정보를 읽는 느낌이 더 강했다.
그림톡의 핵심은 “캐릭터 카드 보기”가 아니라, 내 그림 친구가 처음 살아나는 순간이어야 한다. 그래서 결과 화면을 거의 다시 본다는 마음으로 정리하게 됐다.
1. 처음 결과 화면이 왜 아쉬웠나
초기 결과 화면은 대략 이런 구조였다.
- 내 그림
- 이름
- 정체
- 성격
- 첫 인사
- 친구의 질문
- 실제 응답
- 목소리
- 다시 말 걸기
- 최근 대화
정보가 빠진 건 아니었다. 오히려 너무 많았다.
문제는 이 요소들이 거의 같은 무게로 놓여 있었다는 점이다. 사용자는 “만났다”기보다 “결과를 읽는다”는 느낌을 먼저 받게 된다.
특히 아래 요소들이 그런 인상을 강하게 만들었다.
- 정체
- 성격 태그
- 실제 응답 텍스트
- 최근 대화 기록
- 과한 보조 설명 문구
이런 것들은 나쁘다기보다, 첫 화면에서 너무 앞에 있으면 안 되는 정보였다.
2. 기준을 다시 세웠다
이 화면에서 첫 3초 안에 강하게 보여야 하는 게 뭔지를 다시 정리했다.
내가 최종적으로 남기고 싶었던 핵심은 딱 다섯 가지였다.
- 내 그림
- 친구 이름
- 첫 인사 말풍선
- 친구 목소리 듣기
- 다시 말 걸기
이 다섯 개만 제대로 보이면, 사용자는 설명을 읽지 않아도 이 화면이 무엇인지 바로 이해할 수 있다.
반대로 아래 정보는 2차 정보로 내려도 된다고 판단했다.
- 성격 태그
- 친구의 정체 설명
- 실제 응답 전체 텍스트
- 최근 대화 기록
즉, 핵심은 “무엇을 더 넣을까?”가 아니라 “무엇을 뒤로 뺄까?”였다.
3. 결과 화면을 장면 중심으로 다시 정리했다
가장 먼저 한 건 상단 인상을 바꾸는 일이었다.
영문 라벨이나 내부 구조처럼 보이는 표현은 걷어냈다. 예를 들어 FIRST MEETING 같은 표현은 기획자 입장에서는 의미가 있지만, 실제 사용자 경험에는 큰 도움이 되지 않는다.
대신 결과 화면은 그냥 이렇게 시작하게 했다.
- 네 그림 친구가 처음 인사했어
이 한 줄이면 충분했다.
그 아래에는 설명보다 장면 요소를 먼저 놓았다.
- 내 그림
- 친구가 방금 말을 걸었다는 짧은 문장
- 친구 이름
- 첫 인사 말풍선
- 짧은 follow-up 질문
- 친구 목소리
- 다시 말 걸기 버튼
이 순서로 바꾸고 나니, 화면이 “정보 정리 카드”보다 “막 살아난 친구와 마주한 장면” 쪽에 더 가까워졌다.
4. 실제로 많이 한 일은 ‘삭제’였다
이번 작업에서 인상 깊었던 건, 새로운 기능을 넣기보다 오히려 빼는 작업이 훨씬 많았다는 점이다.
덜어낸 것들
- hero 근처의 과한 설명 문구
- 결과를 해설하는 micro copy
- 너무 앞에 있던 성격/정체/응답 정보
- 영문/내부용 라벨
뒤로 내린 것들
- 친구를 더 알아보기
- 방금 나눈 말 보기
- 실제 응답 텍스트
이 정보들은 완전히 없애지 않았다. 다만 처음 보는 화면의 주인공 자리에서는 내렸다.
그 결과 기본 화면은 훨씬 짧아졌고, 정말 필요한 사람만 아래 detail을 펼쳐서 보게 만들 수 있었다.
5. hero fallback도 같이 정리했다
UX를 다듬다 보니 의외로 거슬렸던 게 하나 더 있었다. 실제로 사용자가 찍은 그림이 없을 때, 일부 mock/dev 상황에서 generic한 큰 캐릭터 얼굴이 hero처럼 보일 수 있다는 점이었다.
실서비스에서는 보통 실제 그림이 들어오니까 치명적인 문제는 아니었다. 하지만 개발 중 캡처를 뜨거나 목업을 볼 때 이 낯선 얼굴이 먼저 보이면, 전체 경험 인상이 흐려졌다.
그래서 원칙을 다시 잡았다.
- hero = 내 그림
- fallback hero = 따뜻한 빈 프레임
- hero = 낯선 캐릭터 얼굴 ❌
이후 CapturePreviewCard를 기준으로 통일해서,
- 이미지가 있으면 실제 그림을 보여주고
- 이미지가 없으면 조용한 paper-tone placeholder를 보여주도록 바꿨다.
작은 수정이었지만, 화면 인상이 훨씬 덜 불안해졌다.
6. 결과 화면 카피도 끝까지 다듬었다
구조를 바꾼 뒤에도 문구가 설명적이면 금방 다시 제품처럼 느껴진다. 그래서 마지막엔 마이크로 카피를 계속 줄이는 작업을 했다.
예를 들면 이런 식이었다.
- “이 친구를 조금 더 보기” → “이 친구 더 알아보기”
- “방금 주고받은 말 보기” → “방금 나눈 말 보기”
- “이번엔 목소리 대신 글로 먼저 인사했어” → “이번엔 글로 먼저 인사했어”
차이는 작아 보이지만, 이런 문장들이 쌓이면 화면 전체 톤이 달라진다.
특히 아이 경험에서는 문장이 설명보다 장면을 방해하지 않는 것이 더 중요하다고 느꼈다.
7. mock/dev용 UI도 운영 흐름에서 분리했다
개발할 때는 image_only, audio_only, image_audio 토글이 꽤 유용했다. 하지만 이게 운영 화면에 섞이면 안 된다.
그래서 마지막엔 mode toggle 노출 조건도 정리했다.
- mock + dev 에서만 보이기
- live / production 에서는 숨기기
이렇게 해두면 개발 편의는 유지하면서도, 실제 사용자 화면은 더 단순하게 가져갈 수 있다.
이런 정리는 기능 추가처럼 보이지 않지만, 제품 완성도에는 꽤 직접적으로 영향을 준다.
8. 이 작업에서 얻은 가장 큰 기준
이번 결과 화면 작업을 하면서 가장 크게 남은 기준은 이거였다.
예쁜 정보 화면보다, 감정이 먼저 느껴지는 장면이 더 중요하다.
처음엔 이것저것 많이 보여주는 쪽이 더 친절해 보였다. 하지만 실제로는 정보량이 많을수록 감정선이 약해졌다.
오히려 사용자가 바로 느껴야 하는 건 아래였다.
- 아, 내 그림이 살아났구나
- 이 친구가 지금 나한테 말을 걸었구나
- 한번 더 말해보고 싶다
이 세 감정이 생기면, 나머지 정보는 뒤에 있어도 충분했다.
마무리
결과 화면을 다듬는 과정은 단순히 UI 정리를 하는 일이 아니었다. 그림톡이 어떤 제품인지 다시 확인하는 과정에 더 가까웠다.
처음에는 정보가 많을수록 좋다고 생각했지만, 결국 중요한 건 무엇을 보여줄까보다 무엇을 먼저 느끼게 할까였다.
지금의 결과 화면은 예전보다 훨씬 덜 설명적이고, 대신 더 장면 중심적이다. 그리고 그림톡이라는 프로젝트가 어디에 힘을 줘야 하는지도 조금 더 분명해졌다.
다음 단계에서는 이 흐름을 바탕으로 실제 대화 품질, 멀티턴 경험, 그리고 아이가 더 오래 머물게 만드는 리듬을 계속 다듬어가게 될 것 같다.