onClick 에 충분한 느림이 필요하다.

신입 개발자로서 첫 번째 프로젝트에 투입되어 고군분투할 때의 이야기다.
당시의 나는 입사 후 첫 로그인 기능을 구현 후 뿌듯함에 젖어있었다.
클라이언트 서버와 API서버는 서로 빠르게 통신하며 콘솔창에 '로그인 성공'이라는 텍스트를 출력하였다.
로그인 버튼을 누르기만 하면, 체감할 수 없는 빠른 속도로 Response를 받아왔다.
개발자로서의 덕목중 하나는 더 빠르고, 더 효율적으로 데이터를 처리하는것이다.

그렇다면 나는 프론트엔드 개발자로서 로그인 기능을 완벽하게 구현 한 것일까?
 

사용자에게 있어 onClick Method는 Hello! 다.

똑-딱!
눈코 뜰 새 없이 빠르게 동작하는 기능이 항상 좋은 로직은 아니다.
사용자에게 있어 '클릭' 이란 내가 만든 기능과 만나기 위한 첫 인사와 같기 때문이다.

개발자로서 생애 첫 모임에 참석한 날을 기억해보자.

내가 누군가에게 인사를 하면,
" 안녕하세요. 저는 홍길동 입니다."

우리는 상대방으로 부터 다음과 같은 반응을 기대한다.
" 반갑습니다. 저는 김철수 입니다."
" 잘부탁드립니다. "

상대방의 인사에 다짜고짜 '그래! 알겠어! 반갑다!' 하고 화답하는 사람은 좋은 커뮤니케이터가 아니다.

이처럼 그저 빠르기만 한 onClick Method는 사용자에게 예기치 못한 동작일 수 있다.

cover2.png

반드시 매력적인 Loading 에 대해 고민해야 한다.

내가 만든 기능이 사용자와 매력적으로 커뮤니케이션하기 위해서는 다음과같은 고민이 필요하다.

  • 5 step (요청 - 요청 중 - 응답 - 응답 중 - 동작완료) 설계 하기
    요청과 응답 사이의 프로세스를 반드시 검토해야 한다고 생각한다.
    최대한 빠른 응답이 필요한지, 사용자에게 충분한 기다림이 주어져야 하는지 판단하고 효율적인 초기 설계를 가져가자.
  • 시각적인 장치 고민하기
    사용자에게 Loading 을 표현하는 방법은 여러가지가 있다.
    팝업창?   안내문구?   페이지 이동?
    어떻게 하면 사용자가 바라는 최고의 응답을 할 수 있을지 고민해보자.
    분명 디자이너에게 일임할 수도 있는 부분이지만, 개발자와 합의되지 않은 방법은 markup 단계에서 이슈가 발생 할 수 있다.
     

나 혼자 고민하기에는 매우 어려운 영역이다.
앞서 언급한 것 처럼 기획자, 디자이너와 충분한 커뮤니케이션을 통해 더 훌륭한 결과물을 만들 수 있다.
혹은 다른 서비스들의 Loading 을 관찰하고 모방하는것도 재미있는 일이 될 것이다.