웹사이트 프로토타입 만드는 법: 제작부터 검토까지 5단계

웹사이트 프로토타입은 화면 구성과 사용 흐름을 개발 전에 시험하는 데 쓰입니다. 시작할 때는 사이트 전체를 연결하려 하지 말고 예약이나 구매처럼 중요한 과업 하나를 고르세요. 화면 구조를 잡고 → 실제 내용과 상태를 넣고 → 화면을 연결하고 → 사용자가 과업을 수행하는지 관찰한 다음 → 개발에 필요한 결정을 전달하는 다섯 단계로 진행하면 됩니다. 이 글에서는 식당 예약을 예로 듭니다.

Pixso의 프로토타이핑 기능으로 날짜 선택, 예약자 정보 입력, 오류 안내, 예약 완료 화면을 연결해 볼 수 있습니다. 프로토타입은 예약이 실제로 접수되는 서비스가 아니라, 화면에서 어떤 선택과 피드백이 필요한지 검토하는 도구입니다.

1. 와이어프레임으로 구조 정하기

먼저 누가 어떤 목적으로 사이트를 이용하는지 정합니다. 필요한 정보와 주요 버튼을 간단한 도형과 텍스트로 배치하면 화면의 우선순위를 검토하기 쉽습니다. 식당 예약이라면 사용자는 가능한 날짜와 시간을 찾고, 인원수를 정하고, 연락처를 입력한 뒤 예약 결과를 확인해야 합니다.

처음에는 네 장의 화면이면 충분합니다. 첫 화면에는 날짜·시간·인원 선택, 둘째에는 이름·연락처 입력, 셋째에는 입력 오류, 마지막에는 예약 내용 확인을 놓습니다. 완료 화면에서 날짜와 인원수가 다시 보이지 않으면 사용자가 결과를 확신하기 어렵습니다. 와이어프레임 단계에서 이 누락을 발견하면 장식 작업을 되돌리지 않아도 됩니다.

각 화면마다 가장 중요한 행동을 하나씩 적어 보세요. 예를 들어 날짜 화면은 ‘가능한 시간 고르기’, 입력 화면은 ‘연락 방법 남기기’입니다. Pixso 리소스 커뮤니티의 템플릿을 참고하더라도 실제 서비스의 문구와 항목으로 바꿔 사용하세요.

2. 실제 콘텐츠와 화면 상태 만들기

구조를 정한 뒤에는 실제 문구, 색상, 이미지와 컴포넌트를 배치합니다. 정상 상태만 만들지 말고 입력 오류, 빈 목록, 로딩 중 화면도 함께 준비하세요. 예약 가능한 시간이 없는 날짜, 연락처 형식이 잘못된 경우, 접수 중 버튼을 다시 누르는 경우처럼 실제 이용 중 생길 장면이 중요합니다.

버튼과 입력창

‘다음’만 반복하기보다 단계에 맞는 라벨을 씁니다. 날짜 화면에서는 ‘시간 선택’, 마지막 단계에서는 ‘예약 내용 확인’처럼 누른 뒤 일어날 일을 예측하게 하세요. 기본, 호버, 비활성 상태를 구분하되 비활성 이유를 필요한 곳에 함께 안내합니다.

오류와 빈 상태

이메일이 빠졌다면 해당 입력창 가까이에 무엇을 입력해야 하는지 적고, 이미 입력한 이름과 전화번호는 유지해야 합니다. ‘오류가 발생했습니다’라는 팝업 하나로 끝내면 사용자는 어느 항목을 고쳐야 할지 모릅니다. 예약 가능한 시간이 없다면 다른 날짜를 고를 수 있는 경로도 보여 주세요. 오류는 색상만으로 전달하지 말고 문구와 위치로도 알립니다.

화면 크기와 실제 문구

데스크톱과 모바일에서 정보의 순서와 주요 기능이 유지되는지 살펴보세요. 넓은 화면의 여러 열을 좁은 화면에서 어떻게 쌓을지 정하고, 긴 식당 이름이나 두 줄로 바뀌는 버튼 라벨도 넣어 봅니다. 임시 문구로는 줄바꿈과 여백 문제를 찾기 어렵습니다. Pixso의 오토 레이아웃과 컴포넌트는 간격과 반복 요소를 관리하는 데 도움이 되지만, 실제 모바일 브라우저에서의 구현 결과는 별도로 확인해야 합니다.

3. 화면과 인터랙션 연결하기

주요 버튼을 다음 화면에 연결하고, 팝업을 열고 닫는 동작을 설정합니다. 시작 화면에서 과업을 완료할 때까지 흐름이 끊기지 않도록 연결하세요. 이 예에서는 날짜 선택 → 예약자 정보 → 내용 확인 → 완료가 기본 경로입니다. 이메일이 비어 있으면 오류 상태로 이동하고, 수정 뒤에는 입력 단계로 돌아갈 수 있어야 합니다.

클릭, 탭, 호버처럼 대상 기기에 맞는 트리거를 선택합니다. 모바일에서 호버만으로 메뉴가 열리도록 만들면 실제 사용 방법과 맞지 않습니다. 화면 전환은 화려함보다 현재 단계와 다음 행동을 이해시키는 데 초점을 맞춥니다. 연결을 마친 뒤에는 첫 화면에서 끝까지 직접 눌러 보고, 뒤로 갔다가 다시 진행할 때 선택한 날짜가 어떻게 보이는지도 확인하세요.

4. 사용자 테스트하고 개선하기

참여자에게 ‘토요일 저녁 두 명의 자리를 예약해 주세요’처럼 구체적인 과제를 주고 직접 진행하게 합니다. 조작 방법을 미리 알려 주지 말고, 막힌 위치, 되돌아간 이유, 잘못 읽은 안내를 관찰하세요. 완료 여부뿐 아니라 왜 어려웠는지도 확인하는 것이 중요합니다.

관찰 결과는 화면 이름과 행동을 함께 적으면 수정으로 이어집니다. 예를 들어 ‘날짜 선택 화면에서 선택 가능한 시간이 예약 불가 시간과 비슷하게 보여 두 번 눌렀다’라고 기록합니다. 그러면 색만 바꿀지, 상태 라벨을 넣을지, 비활성 시간을 숨길지 검토할 수 있습니다. ‘사용성이 나쁘다’라는 결론만 적어 두면 다음 행동을 정하기 어렵습니다.

Pixso의 공유 링크로 팀과 같은 프로토타입을 검토하고, 화면 위 댓글에 문제와 수정 이유를 남길 수 있습니다. 변경 후에는 같은 과업을 다시 진행해 흐름이 나아졌는지 살펴보세요. 소수의 관찰만으로 전체 이용자의 행동을 단정하기보다, 발견한 문제와 다음 확인 방법을 구분해 기록합니다.

5. 개발에 필요한 화면과 조건 전달하기

확정한 화면, 상태별 문구, 주요 인터랙션과 예외 조건을 개발자에게 전달합니다. Pixso에서 크기, 간격, 스타일과 에셋을 함께 공유하면 구현할 때 같은 기준을 참고할 수 있습니다. 프로토타입으로 결정한 내용과 실제 구현에서 추가로 정할 사항을 구분해 정리하세요.

식당 예약 예시라면 가능한 시간 목록의 데이터 출처, 중복 예약 처리, 예약 완료 메시지를 언제 보내는지는 시각적 연결만으로 결정되지 않습니다. 화면 옆에 ‘시간이 마감되면 다른 시간 선택으로 돌아간다’, ‘접수 중에는 중복 제출을 막는다’처럼 개발과 기획이 확인해야 할 조건을 남깁니다. 클릭 가능한 프로토타입과 이 조건이 함께 있어야 전달받은 팀이 같은 동작을 구현하기 쉽습니다.

마지막으로 프로토타입을 다시 열어 네 가지를 점검하세요. 주요 과업이 끝까지 연결되는지, 오류 뒤에 복구할 수 있는지, 모바일에서 핵심 행동이 보이는지, 화면에 적힌 조건이 개발 메모와 모순되지 않는지입니다. 이 확인이 끝나면 디자인 파일은 예쁜 화면 모음이 아니라 실제 논의와 구현에 쓰이는 기준이 됩니다.