그림톡 만들기 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 정리를 하는 일이 아니었다. 그림톡이 어떤 제품인지 다시 확인하는 과정에 더 가까웠다.

처음에는 정보가 많을수록 좋다고 생각했지만, 결국 중요한 건 무엇을 보여줄까보다 무엇을 먼저 느끼게 할까였다.

지금의 결과 화면은 예전보다 훨씬 덜 설명적이고, 대신 더 장면 중심적이다. 그리고 그림톡이라는 프로젝트가 어디에 힘을 줘야 하는지도 조금 더 분명해졌다.

다음 단계에서는 이 흐름을 바탕으로 실제 대화 품질, 멀티턴 경험, 그리고 아이가 더 오래 머물게 만드는 리듬을 계속 다듬어가게 될 것 같다.