화면 그림만으로는 개발이 안 되는 이유

디자이너에게 받은 화면 그림 스무 장을 개발사에 넘긴 대표님이 계셨습니다. 그림은 깔끔했습니다. 그런데 일주일 뒤 개발사에서 질문 목록이 왔습니다. 길이가 그림보다 길었습니다.

「예약 버튼을 두 번 누르면 어떻게 되나요」, 「취소는 언제까지 되나요」, 「사진을 안 올리면 다음으로 넘어가나요」. 그림에는 답이 없는 질문들이었습니다. 대표님은 하나씩 답하다가 지치셨고, 일정은 그만큼 밀렸습니다.

화면 그림은 무엇이 보이는지를 말해 줍니다. 하지만 개발자는 무엇이 일어나는지를 알아야 만들 수 있습니다. 이 둘 사이를 메우는 것이 기능 정의입니다.

핵심은 화면 그림이 「무엇이 보이는지」만 말해 주고 「무엇이 일어나는지」는 말해 주지 않는다는 점입니다. 개발자는 버튼을 누르면 어디로 가는지, 어떤 규칙이 있는지, 실패하면 무엇을 보여 주는지를 알아야 만들 수 있습니다. 그림 옆에 이 내용을 적은 기능 정의를 붙여야 개발이 멈추지 않습니다.

그림이 말해 주지 않는 것

그림 속 버튼은 늘 잘 눌리고, 목록은 늘 예쁘게 채워져 있습니다. 실제 서비스는 그렇지 않습니다. 인터넷이 끊기고, 사용자는 칸을 비워 두고, 같은 버튼을 여러 번 누릅니다.

그림에 빠진 내용은 크게 세 가지입니다.

• 동작. 버튼을 누르면 어디로 가고, 무엇이 저장되는지
• 규칙. 누가 볼 수 있는지, 언제까지 바꿀 수 있는지
• 예외. 실패했을 때, 비어 있을 때, 기다릴 때 무엇을 보여 주는지

이 셋이 비어 있으면 개발자는 짐작으로 채웁니다. 짐작이 맞으면 다행이고, 틀리면 다시 만듭니다.

기능 정의는 이렇게 적습니다

어려운 문서일 필요는 없습니다. 화면 옆에 표 하나를 붙인다고 생각하시면 됩니다. 예약 화면이라면 이런 모양입니다.

요소	누르면	예외
시간 선택	고른 시간이 강조되고 금액이 바뀝니다	이미 찬 시간은 고를 수 없게 흐리게 보입니다
예약하기 버튼	결제 화면으로 넘어갑니다	시간을 고르지 않았으면 안내 문구를 띄웁니다
예약하기 버튼	처리 중에는 다시 누를 수 없습니다	처리에 실패하면 다시 시도할 수 있게 합니다
취소 버튼	확인 창을 띄운 뒤 취소합니다	정해진 기한이 지나면 버튼을 숨깁니다

칸을 채우다 보면 대표님이 정해야 할 일이 드러납니다. 취소 기한을 하루 전으로 할지, 당일까지 허용할지 같은 것입니다. 이건 개발자가 정할 일이 아닙니다. 사업을 하는 분이 정할 일입니다.

표를 쓸 때 요령이 하나 있습니다. 화면 위의 요소를 위에서 아래로 훑으며 하나씩 적는 것입니다. 글자 칸, 버튼, 목록, 사진 자리마다 「누르면」과 「예외」를 붙입니다. 누를 수 없는 요소라면 「언제 바뀌는지」를 적습니다. 이렇게 하면 빠뜨리는 칸이 거의 없습니다.

문장은 짧을수록 좋습니다. 「적절히 처리한다」 같은 말은 쓰지 않습니다. 개발자가 읽고 바로 만들 수 있게 「안내 문구를 띄우고 이전 화면에 머문다」처럼 적습니다. 무엇을 보여 주고 어디로 가는지가 문장에 들어 있어야 합니다.

예외 화면이 일정의 절반을 가릅니다

현장에서 보면 일정이 밀리는 곳은 대개 정상 흐름이 아닙니다. 예외 흐름입니다. 결제가 실패했을 때, 목록이 비었을 때, 권한이 없는 사람이 들어왔을 때입니다.

이런 상황은 화면 그림에 거의 그려지지 않습니다. 그래서 개발 막바지에 한꺼번에 튀어나옵니다. 처음부터 화면마다 「비었을 때, 기다릴 때, 실패했을 때」를 한 줄씩 적어 두면 막바지의 혼란이 크게 줄어듭니다.

• 비었을 때. 첫 방문이라 목록에 아무것도 없을 때 무엇을 보여 줄지
• 기다릴 때. 불러오는 동안 화면이 멈춰 보이지 않게 할지
• 실패했을 때. 무엇이 잘못됐고 다음에 무엇을 하면 되는지

질문이 줄면 일정이 지켜집니다

기능 정의가 붙은 화면을 받으면 개발자의 질문은 확인으로 바뀝니다. 「이렇게 이해했는데 맞나요」 정도입니다. 답하는 데 하루가 걸리던 질문이 몇 분으로 줄어듭니다.

화면설계는 그림과 설명을 함께 그리는 일입니다. 화면마다 누르면 무슨 일이 일어나는지, 예외는 어떻게 하는지까지 적은 기획서가 있으면 개발은 다른 곳에 맡겨도, 직접 하셔도 흔들리지 않습니다. 그림을 넘기기 전에 그 옆의 빈칸부터 채워 보시기를 권합니다.

자주 묻는 질문

기능 정의서와 화면설계는 무엇이 다른가요?

화면설계는 화면에 무엇이 어디에 보이는지를 그린 것이고, 기능 정의는 그 화면에서 무엇이 일어나는지를 적은 것입니다. 실무에서는 둘을 한 문서에 함께 담는 경우가 많습니다. 개발자에게는 둘 다 필요합니다.

디자이너에게 받은 화면 시안으로 바로 개발을 맡겨도 되나요?

맡길 수는 있지만 개발 중에 질문이 많이 돌아올 가능성이 큽니다. 시안에는 대개 동작, 규칙, 예외가 빠져 있기 때문입니다. 화면마다 누르면 일어나는 일과 예외를 표로 붙여 넘기시기를 권합니다.

예외 상황은 어디까지 적어야 하나요?

화면마다 비었을 때, 기다릴 때, 실패했을 때 세 가지를 한 줄씩 적는 것부터 시작하면 됩니다. 여기에 권한이 없는 사람이 들어왔을 때를 더하면 대부분의 경우가 채워집니다. 문장은 무엇을 보여 주고 어디로 가는지가 드러나게 씁니다.