당신은 자신의 화면에 대해서 다 알고있나요?
프로덕트 디자이너로서 실무를 진행하면서 혹시 '화면'만 그리고 있지는 않나요? 혹은 ‘클라이언트’와 ‘서버’의 관계를 이해하며 설계를 진행하고 있나요? 만약 그렇지 않다면, 당신은 UI가 실제 환경에서 어떻게 작동하는지 놓치고 있을 가능성이 큽니다.
디자이너가 보는 페이지 vs 개발자가 보는 페이지
뎁스(Depth)가 있는 프로세스를 디자인했다고 가정해 봅시다. 예를 들어 장바구니 → 주문서 → 결제로 이어지는 흐름입니다. 디자이너는 이를 장바구니, 주문서, 결제라는 총 3개의 페이지라고 생각하기 쉽습니다. 하지만 실제 개발 환경, 특히 모던 웹 환경에서는 이 모든 과정이 물리적으로는 단 하나의 페이지에서 작동할 수 있습니다.
다음 화면으로 넘어갈 때 데이터는 어디에 저장되고, 무엇을 기준으로 이어질까요? 많은 디자이너가 이 구조를 깊게 생각하지 않은 채 정지된 화면만 완성하곤 합니다. 이를 제대로 설계하기 위해서는 SPA(Single Page Application)라는 개념을 이해해야 합니다.
▲ 디자이너가 제작한 3개의 화면
▲ 실제 SPA 환경에서의 화면
SPA란?
▲ MPA 방식: 페이지 이동할때마다 새로 HTML을 그림
▲ SPA 방식: 페이지 이동할때 필요한 데이터만 받음
SPA는 말 그대로 하나의 HTML 페이지에서 동작하는 애플리케이션입니다. 전통적인 방식인 MPA(Multi-Page Application)는 페이지를 이동할 때마다 서버로부터 새로운 HTML을 전송받아 화면 전체를 '깜빡'이며 새로 그립니다. 반면, SPA는 초기에 앱 구동에 필요한 리소스(HTML/CSS/JS)를 로드한 뒤, 화면 이동 시에는 필요한 데이터(Data)만 서버에서 받아와 부분적으로 내용을 갈아 끼우는 방식입니다.
예를 들어 장바구니에서 주문서로 넘어갈 때, 화면 전체를 새로고침하는 것이 아니라 틀은 유지한 채 주문서에 필요한 데이터만 쏙 가져와 보여주는 것이죠. 덕분에 사용자는 훨씬 빠르고 부드러운 경험을 할 수 있습니다.
마무리
구조를 아는 디자이너가 설계를 주도한다
내가 만든 UI가 기술적으로 어떤 동작을 수행하는지 아는 것은 매우 중요합니다. 아무리 IA와 피쳐 리스트를 완벽하게 짠다고 해도, 실제 구현 단계에서는 예상치 못한 엣지 케이스(Edge Case)가 발생하기 마련입니다. 이는 마치 서로 다른 언어로 번역하는 과정에서 정보가 소실되는 것과 같습니다.
훌륭한 번역가가 문맥과 뉘앙스까지 살려 번역하듯, 훌륭한 디자이너는 내 디자인이 코드로 변환될 때 어떻게 작동할지 예측할 수 있어야 합니다. 데이터가 어떻게 이동하고 유지되는지 이해하는 디자이너는 개발자와 더 효율적으로 합의할 수 있고, 예외 상황에서도 흔들리지 않는 탄탄한 사용자 경험을 설계할 수 있습니다. 결국, 구조를 이해하는 디자이너가 더 완성도 높은 제품을 만드는 법입니다.
참고자료