정책, 기능, 구조 정의 없이 앱과 웹의 화면 설계가 가능할까?

앞의 글에서 앱/웹 분석/설계에 대해 이야기했습니다. 그러면서 화면 설계에 앞서 진행되는 앱/웹 분석/설계에 대해 정리하였습니다. 그럼 이를 다시 분석/설계 시 진행되는 정책, 기능, 구조 정의가 없이 화면 설계를 하면 어떤 일이 발생할지에 대해 정리하면서 기획적 사고에 대해 생각해 보는 시간을 가지도록 하겠습니다.

 

 

 

정책, 기능, 구조 정의가 없다는 의미

 

우선 앱/웹 정책, 기능, 구조(여기서 구조는 톤 앤 매너를 의미합니다) 정의가 없다는 것은 어떤 기획적 의미를 가지는지 생각해 보겠습니다.

 

우리는 앱이나 웹 회원 가입을 할 때 조금씩 입력해야 하는 내용이 다른 것을 알 수 있습니다. 이러한 입력 정보는 앱/웹이 어떤 서비스 제공을 지향하는지에 따라 달라집니다. 그리고 이러한 회원 가입 정보를 받겠다고 결정하는 것을 회원 정책의 일부라 합니다.

 

그렇다면 여기서 또 다른 부분을 다시 생각 보겠습니다. 

 

어떤 앱이나 웹은 이메일 넣고 시작해야 하지만 다른 앱/웹은 그냥 카카오나 구글 계정 연동으로 가입이 완료되기도 합니다. 이는 회원 가입 기능이라 할 수 있습니다.

 

또 어떤 앱/웹은 내용을 입력하면 화면이 전환되고 다시 새로운 입력 폼이 나오기도 합니다. 다른 앱/웹은 그냥 한 페이지에서 등록이 끝나기도 합니다. 때로는 입력 시마다 내용이 맞는지 틀리는지 알려주는 앱/웹도 있고, 전체 입력 후 등록 시 확인 후 잘못 적은 부분을 알려주기도 합니다.

 

또 최종으로 등록한 메일로 회원 가입 인증 번호를 발송하여 이를 확인한 후 회원 가입이 끝나는 앱/웹도 있지만, 그냥 등록 내용만 다 적으면 가입이 끝나는 앱/웹도 있습니다.

 

심지어 한 명이 여러 아이디를 만들 수 있는 앱/웹도 있지만, 한 명당 한 아이디만 만들 수 있는 앱/웹도, 세 개까지는 아이디 생성이 가능한 앱/웹도 있습니다.

 

이렇듯 앱/웹은 정책이 정해지면, 이 정책에 해당하는 기능 및 처리/이용 구조가 형성되게 됩니다.

 

일반적으로 사용자는 이렇게 결정된 내용을 토대로 개발된 앱/웹을 이용하고 또 무엇을 입력해야 할지, 이용을 위해 무엇을 해야 할지 판단할 수 있게 됩니다.

 

그리고 앱/웹마다 조금씩 다른 이러한 이용 방식을 통해 사용자는 각 앱/웹을 구체적으로 기억하게 됩니다. 그리고 차이를 느끼고 이를 감안하여 이용할 앱/웹을 선택하게 됩니다.

 

결국 정책, 기능, 구조 정의가 없다는 말은 사용자가 이용할 앱/웹이 구체적이지 않다는 말이 됩니다. 

 

이 말을 회원 가입의 예로 들면, 어떤 때는 이메일로 가입이 가능하고, 어떤 때는 이메일 가입이 안되고 카카오톡 가입만 되고, 다른 때는 아이디/비번 생성 후 가입이 되는 앱/웹이 되는 것입니다. 이러한 앱/웹이 사용성에서 매우 안 좋을 것은 예상이 쉽습니다. 이를 기획적으로 나쁜(안 좋은) UX라 합니다.

 

물론 개발도 복잡하고 어려워질 것입니다. 이는 다시 버그 가능성을 높이고, 이용 플로워의 복잡성을 야기하게 됩니다. 이 또한 부정적 UX에 기여하는 요소가 됩니다.

 

 

          

정책, 기능, 구조 정의 없이 화면 설계를 할 경우 

 

결국 정책, 기능, 구조 정의가 없다는 말은 네이버 일수도 있고, 구글일 수도 있으면서, 인스타그램이면서, 유튜브인 앱/웹이라는 말이 됩니다.

 

상식적으로 이런 앱/웹은 존재하지 않습니다.

 

아마 개발을 하려고 하는 회사가 있었을 수도 있습니다. 그러나 우리가 모르는 것은 아마 개발에 실패하였던지, 사용자가 이런 앱/웹을 쓰고 싶지 않아 했기 때문일 수 있습니다.

 

만약 이런 상황에서 화면 설계를 해야 한다면 같은 화면이 사람에 따라 맞고 틀리다가 생겨날 것입니다. 이 말은 컨펌이 안 난다는 말입니다.

 

일반적으로 화면 설계 기획자가 설계할 수 있는 화면은 수 십 가지도 넘습니다. 이들은 수많은 앱/웹 종류만큼 설계의 정답이 됩니다. 단지 현재 개발 중인 앱/웹의 화면이 아닐 뿐입니다.

 

이중 해당 앱/웹에 맞게 기획자는 선택을 해야 합니다. 이 선택의 기준이 되는 것이 바로 정책, 기능, 구조인 것입니다.

 

그러므로 화면 설계 시 정책, 기능, 구조의 정의는 반드시 필요합니다. 없다면 화면 설계 기획자는 고객 또는 담당자에게 물어가면서 화면을 설계해야 할 것입니다. 쿠팡 화면 설계에 투입된 기획자가 SSG나 지마켓처럼 화면을 설계할 수는 없기 때문입니다.

 

 

 

3개월 안에 화면 설계가 끝나지 않는 이유   

 

결론적으로 앱/웹과 관련한 정책, 기능, 구조 정의가 안되어 있다면 화면 설계 기획자는 이를 하나씩 물어가면서 화면을 설계해야 한다는 말이 됩니다.

 

그런데 결정된 정책, 기능, 구조 정의가 없으므로, 시간에 따라 담당자에 따라 의견이 달라질 수 있다는 말이 됩니다.

 

결국 물어가면서 화면을 설계하는 것은 이미 사전 설계(정책, 기능, 구조 정의)가 되어 있는 상태에서 화면 설계보다 물어보느라 더 많은 시간이 걸린다는 말이 됩니다.

 

여기다 결정된 사항이 없으므로 그때그때 추가 정책, 기능, 구조가 나올 수도 있고, 기존 들었던 내용이 바뀔 수도 있다는 말이 됩니다. 이 경우 화면 설계는 바뀌어야 합니다. 작업을 두 번 세 번 해야 하는 것입니다.

 

이런 이유로 일반적으로 3달 안에 충분히 끝날 수 있는 화면 설계 작업은 5달이 지나도 끝나지 않게 됩니다. 

 

여러 기획 PA가 일을 하는 경우 공통 및 화면 설계 기준이 변경/추가되는 경우 이와 비슷한 일이 생기게 될 것입니다. 공통이나 화면 설계 기준이 변경/추가된다는 말은 변경/추가 그 자체가 문제라기보다는 기획을 리딩하는 총괄 기획자가 내용을 잘 모른다는 말이 되기에 문제가 있는 것입니다. 그래서 기획 PA들은 정책, 기능, 구조가 정의되지 않고 화면 설계하는 상황과 비슷한 상황에 처하게 됩니다.