하이 파이 프로토타입

상자와 선으로만 그린 시안은 값싸고 빠르지만 답하지 못하는 질문이 있습니다. 버튼에 적을 말 세 개 중 어느 것이 덜 헷갈리는지, 화면에 버튼이 둘일 때 사람이 의도한 쪽을 누르는지 같은 것들입니다. 회색 상자에 "버튼" 이라고만 적힌 상태에서는 아무도 그 질문에 답할 수 없습니다.

페이지덱에서 실제로 걸렸던 자리가 그것입니다. 민서가 권한 설정 화면을 상자와 선으로 그려 와 리뷰를 돌렸고 다들 괜찮다고 했습니다. 그런데 개발이 끝나고 보니 "공유" 와 "초대" 버튼이 나란히 같은 크기로 앉아 있었고, 문서를 팀에 넘기려던 사용자 절반이 초대를 눌렀습니다. 리뷰에서 그 둘은 회색 상자 두 개였고, 보는 사람들은 머릿속에서 알아서 구분이 되는 화면을 상상했습니다.

회색 상자의 또 다른 문제는 사람들이 판단을 미룬다는 점입니다. 덜 만들어진 것을 보면 "완성되면 괜찮아지겠지" 하고 넘어갑니다. 실제 화면에 가깝게 만들어 놓으면 그 유예가 사라져서, 지금 이대로 나가면 어떤 일이 생길지를 그 자리에서 말하게 됩니다.

페이퍼 프로토타입부터 이어지는 충실도 사다리의 맨 위 칸이 여기입니다. 종이로 흐름을 정하고 구조가 잡힌 다음, 문구와 색까지 정해야 하는 단계에 오면 이쪽으로 옮깁니다.

만들 때 채워야 하는 것은 여섯 가지입니다.

1. 실제로 쓸 문구. 자리를 채우려고 넣는 의미 없는 글자를 두면 확인하려던 것이 통째로 사라집니다. "여기에 설명" 이라고 적힌 자리를 보고는 아무도 그 설명이 이해되는지 판단하지 못합니다.
2. 실제에 가까운 데이터. 이름 칸에 "홍길동" 만 넣지 않고 부서명이 스무 글자인 경우와 목록 건수가 0건인 경우를 함께 넣습니다. 짧고 예쁜 값만 넣으면 실제 데이터가 들어왔을 때 줄이 밀리는 것을 못 봅니다.
3. 시각 규칙. 색과 글꼴과 간격을 디자인 시스템에서 가져다 씁니다. 재사용 가능한 규칙과 부품을 한 벌로 묶어 둔 기준인데, 여기서 가져다 쓰면 개발이 그대로 구현할 수 있고 시안마다 색이 달라지는 일도 없습니다.
4. 잘 안 풀린 경우의 화면. 아직 보여 줄 내용이 없는 빈 상태, 기다리는 중인 화면, 입력이 틀렸을 때의 화면을 함께 만듭니다. 잘 풀린 경우만 만들면 확인한 것도 절반입니다.
5. 전환과 반응. 누르면 다음 화면으로 넘어가고, 값을 넣으면 화면이 응답합니다. 화면 전환만 진짜처럼 동작하는 클릭 더미와 겹치는 부분인데, 충실도가 높으면 넘어가는 모습까지 실제와 비슷해집니다.
6. 과제 하나를 끝까지 밟는 경로. 시작 화면부터 끝 화면까지 끊기는 데 없이 이어져야 보여 주는 자리에서 쓸 수 있습니다.

무엇을 넣지 않을지도 같이 정합니다. 입력한 값이 실제로 저장되는 것, 검색어에 따라 결과가 달라지는 것, 권한에 따라 갈리는 모든 경우는 대개 만들지 않습니다. 이 목록을 미리 정해 두지 않으면 화면 수가 계속 늘어나 확인하려던 시점보다 만드는 데 시간이 더 듭니다.

만드는 사람은 대개 프로덕트 디자이너입니다. 페이지덱에서는 민서가 만들고 지현이 옆에서 확인할 질문과 과제 문장을 씁니다. 같은 화면이라도 "이 화면 어때요" 를 물을 때와 "문서를 팀 전체에 공개해 보세요" 를 시킬 때 만들어야 하는 화면 수가 다르기 때문에, 질문이 먼저 정해져야 만드는 범위가 정해집니다.

읽는 쪽은 셋입니다.

첫째는 사용자입니다. 다섯 명쯤에게 같은 과제를 주고 어디서 멈추는지를 봅니다. 이 자리를 위해서는 문구와 데이터가 실제에 가까워야 합니다. 그렇지 않으면 참여자가 화면을 해석하는 데 시간을 쓰고, 정작 물어보려던 지점에 닿기 전에 시간이 끝납니다.

둘째는 팀 안입니다. 태오는 여기서 간격과 상태 화면을 읽어 구현합니다. 요구사항 문서에 글로만 적힌 "오류 시 안내" 는 사람마다 다른 화면을 떠올리게 하지만, 시안에 그 화면이 있으면 해석이 하나로 모입니다.

셋째는 회사 바깥입니다. 규원이 투자자에게 보여 주거나 수아가 고객사 데모에서 씁니다. 이 자리가 가장 조심스럽습니다. 실제 화면과 구분이 안 되므로 보는 쪽이 이미 있는 기능으로 받아들이기 쉽고, 그 오해 위에서 계약 일정이 잡히면 뒤늦게 수습해야 합니다. 그래서 바깥에 보여 줄 때는 아직 만들지 않은 화면이라는 말을 먼저 붙입니다.

"다음 주 고객사 데모라서 하이 파이로 만들어 주세요."

밖에 보여 줄 자리이니 실제 화면처럼 보이는 수준이 필요하다는 요청입니다.

"문구는 실제로 쓸 걸로 넣어 주세요. 채움용 글자로 두면 테스트에서 물어볼 게 없어요."

충실도의 핵심이 겉모습이 아니라 내용이라는 것을 짚는 말입니다.

"빈 상태랑 오류 화면도 있나요? 그것까지 있어야 개발 들어갈 수 있어요."

시안을 구현 근거로 쓰는 쪽에서 나오는 요구입니다.

페이지덱이 권한 화면을 다시 만들 때는 순서를 바꿨습니다. 민서가 "공유" 와 "초대" 두 버튼의 문구와 크기만 다르게 한 시안 세 벌을 하이 파이로 만들고, 사용자 다섯 명에게 같은 과제를 줬습니다. 문서를 팀 전체가 보게 만들라는 과제였습니다.

다섯 명 중 넷이 첫 번째 시안에서 초대를 눌렀고, 두 번째 시안에서는 한 명만 그랬습니다. 차이는 문구를 "팀에 공유" 로 바꾸고 초대 버튼을 덜 눈에 띄게 둔 것뿐이었습니다. 회색 상자로는 이 차이를 만들 수도 없고 물어볼 수도 없습니다.

충실도가 높을수록 좋은 시안이라고 생각하기 쉽습니다. 더 많은 것이 들어갔으니 더 낫다고 보는 것이 자연스럽습니다. 그런데 무엇을 확인하려는지에 따라 알맞은 충실도가 달라집니다. 순서가 말이 되는지 보려던 자리에 색까지 다 들어간 화면을 가져가면, 사람들은 순서가 이상하다는 말 대신 파란색이 낫겠다는 말을 합니다. 물어보려던 것이 순서였다면 그 회의는 헛돈 셈이고.

거의 다 만들어진 것으로 받아들이는 오해도 흔합니다. 눌러 보면 화면이 넘어가니 남은 일이 얼마 안 되어 보입니다. 실제로는 정해진 길 바깥에서는 아무것도 동작하지 않는 껍데기입니다. 값이 저장되지 않고 다른 사람의 화면에 반영되지도 않으며, 권한과 예외 처리는 대개 통째로 빠져 있습니다. 이 오해를 그대로 두면 데모를 본 쪽이 다음 주 출시를 기대하게 되고, 만드는 쪽은 애초에 없던 일정을 떠안습니다.