화면설계, 디자인, 프로토타입은 무엇이 다른가

한 학원 원장님이 「디자인까지 다 나왔다」며 화면 열 장을 보여 주셨습니다. 색도 예쁘고 글씨도 반듯했습니다. 그런데 「수강생이 결석하면 이 화면이 어떻게 바뀌나요?」라고 여쭙자 답이 없었습니다.

예쁜 화면은 있었지만, 화면이 무엇을 하는지 정한 문서는 없었습니다. 디자인이 화면설계보다 먼저 나온 경우입니다. 이렇게 되면 디자인을 여러 번 다시 해야 합니다.

핵심은 세 가지가 서로 다른 질문에 답한다는 점입니다. 화면설계는 「무엇을 보여 주고, 누르면 어떻게 되는가」, 디자인은 「어떻게 보이는가」, 프로토타입은 「실제로 눌러 보면 자연스러운가」에 답합니다. 순서는 화면설계, 디자인, 프로토타입 순이 기본입니다.

세 가지를 한눈에 비교합니다

화면설계는 일부러 꾸미지 않습니다. 색이 들어가면 회의가 「버튼 색이 마음에 안 든다」로 흘러가기 때문입니다. 이 단계에서는 내용과 동작만 이야기해야 합니다.

순서를 바꾸면 생기는 일

디자인부터 하면 보기에는 빠릅니다. 하지만 디자인 중에 「여기 쿠폰 칸도 있어야 하네」가 나오면 화면을 다시 그려야 합니다. 화면설계 단계에서는 상자 하나 옮기면 끝날 일이, 디자인 단계에서는 여러 화면의 간격과 배치를 다시 맞추는 일이 됩니다.

개발이 시작된 뒤에 같은 수정을 하면 더 무겁습니다. 그래서 바꿀 일은 가장 가벼운 단계에서 다 바꿔 두는 것이 원칙입니다.

반대로 디자인만 있고 화면설계가 없으면 개발자가 빈칸을 채웁니다. 목록이 비었을 때, 입력을 잘못했을 때, 권한이 없을 때의 화면은 디자인 시안에 잘 나오지 않습니다. 개발자가 알아서 만든 화면은 서로 모양도 말투도 제각각이 됩니다. 화면설계에서 이런 상황을 먼저 적어 두면, 디자이너는 그것까지 그리고 개발자는 그대로 만들 수 있습니다.

프로토타입은 언제 필요한가

모든 서비스에 프로토타입이 필요하지는 않습니다. 다음 경우에 특히 쓸모가 있습니다.

• 가입, 예약, 결제처럼 여러 화면을 이어 가야 하는 흐름이 핵심일 때
• 투자자나 내부 결재자에게 서비스를 보여 줘야 할 때
• 실제 사용자 몇 명에게 먼저 눌러 보게 하고 싶을 때

프로토타입은 화면설계로도 만들 수 있고 디자인으로도 만들 수 있습니다. 흐름만 확인하려면 화면설계 단계의 프로토타입으로 충분합니다.

한 가지 주의할 점이 있습니다. 프로토타입은 진짜처럼 보이지만 뒤에서 아무것도 저장하지 않습니다. 눌러 보니 잘 된다고 해서 기능이 다 만들어진 것은 아닙니다. 프로토타입을 본 뒤에도 「이 버튼을 누르면 무엇이 저장되는가」는 화면설계에 따로 적혀 있어야 합니다.

발주할 때 확인할 말

외주를 맡길 때 「디자인 포함」이라는 말만으로는 부족합니다. 화면설계를 누가 만드는지, 디자인은 몇 화면인지, 프로토타입이 포함되는지를 따로 물어야 합니다. 세 가지를 한 단어로 뭉뚱그리면 나중에 「그건 포함이 아니었다」는 말을 듣기 쉽습니다.

디자인을 맡길 때도 화면설계를 함께 넘기면 「몇 화면인지」가 분명해집니다. 화면 목록이 없으면 디자인 범위도 말로만 정해지고, 관리자 화면이 디자인에 들어가는지 같은 질문이 뒤늦게 나옵니다.

결국 출발점은 화면설계입니다. 메뉴 구조와 화면설계, 기획서가 먼저 정해져 있으면 디자인도 프로토타입도 그 위에서 흔들리지 않고 만들어집니다.

자주 묻는 질문

화면설계 없이 바로 디자인을 맡겨도 되나요?

작은 소개 페이지라면 가능합니다. 하지만 회원, 결제, 관리자 화면이 있는 서비스라면 화면설계 없이 디자인부터 하면 다시 그리는 일이 자주 생깁니다.

와이어프레임과 화면설계는 같은 말인가요?

거의 같은 뜻으로 씁니다. 와이어프레임은 화면 배치를 그린 그림을, 화면설계는 그 그림에 동작과 예외 설명까지 붙인 문서를 가리킬 때가 많습니다.

프로토타입을 만들면 개발이 빨라지나요?

개발 자체가 빨라지지는 않습니다. 대신 개발 전에 흐름의 문제를 찾아 고칠 수 있어서, 개발 중에 되돌아가는 일이 줄어듭니다.