사용자 인터랙션 설계, 입력과 반응을 어떻게 이을까

 

화면 하나를 설계할 때 저는 예전에 버튼의 위치와 색부터 고민하곤 했어요.
그런데 현업에서 몇 번 개발자와 이야기해 보니, 더 자주 문제가 되는 건 "눌렀을 때 무슨 일이 일어나는가"였습니다.
입력이 들어오고, 시스템이 반응하고, 사용자가 그 반응을 이해하는 흐름 전체가 인터랙션이라고 생각해요.
그 흐름을 어떻게 이어야 하는지 제가 정리한 기준을 적어 봅니다.

 

기획서에 "버튼을 누르면 저장된다"라고만 쓰면 비어 있는 부분이 많습니다.
누른 직후에는 어떻게 보이는지, 저장이 끝나면 무엇이 바뀌는지, 실패하면 어떻게 되는지가 빠져 있으니까요.

그래서 입력 하나마다 반응을 세 가지로 나누어 적는 습관을 들였습니다.

• 즉시 반응: 누른 순간 눌렸다는 것을 알려 주는 변화
• 처리 중 반응: 기다리는 동안 보여 줄 상태
• 결과 반응: 성공이나 실패를 알려 주는 화면과 문구

이 세 칸이 채워지면 개발자도 디자이너도 같은 그림을 보게 됩니다.

가정 예시로 게시글 저장 버튼을 채워 보겠습니다.
즉시 반응은 버튼이 눌린 모양으로 바뀌는 것입니다.
처리 중 반응은 버튼이 잠시 비활성이 되고 "저장하는 중"이라는 문구가 보이는 것입니다.
결과 반응은 성공하면 "저장했습니다"라는 안내와 함께 목록으로 돌아가고, 실패하면 입력한 내용을 그대로 둔 채 "저장하지 못했습니다, 다시 시도해 주세요"라고 알려 주는 것입니다.
이렇게 쓰면 한 줄이던 "누르면 저장된다"가 개발과 검수에 쓸 수 있는 명세가 됩니다.

 

같은 기능이라도 반응이 언제 오느냐에 따라 느낌이 크게 달라집니다.
제가 대략 기준으로 삼는 감각은 이렇습니다.

• 누르자마자 바로 보이는 변화는 즉각적이어야 합니다.
• 잠깐 걸리는 처리는 진행 중임을 알리는 표시가 필요합니다.
• 오래 걸리는 처리는 얼마나 남았는지, 기다려야 하는지 떠나도 되는지를 알려야 합니다.

정확한 초 단위 기준은 서비스마다 다르겠지만, 반응이 없는 시간이 길어질수록 사용자는 "고장 났나"라고 의심하더라고요.
이때 사용자는 같은 버튼을 한 번 더 누르게 되고, 중복 요청이 생깁니다.

반대로 반응이 너무 빠르기만 해도 문제가 될 수 있어요.
처리가 눈 깜짝할 사이에 끝나서 화면이 번쩍하고 바뀌면, 사용자는 방금 무슨 일이 있었는지 놓칩니다.
이럴 때는 완료 안내를 잠깐 머물게 해서 일이 끝났다는 사실을 확인할 시간을 주면 좋습니다.

가정 예시를 들어 볼게요.
주문하기 버튼을 누르고 화면이 한동안 그대로라면, 사용자가 두 번 세 번 누를 수 있습니다.
그러면 같은 주문이 여러 건 들어갈 위험이 생겨요.
그래서 누른 직후에 버튼을 비활성 상태로 바꾸고 "주문 처리 중"이라고 보여 주는 설계가 필요합니다.

처리 중 표시도 종류를 나누어 쓰는 편이 좋다고 생각해요.
몇 초 안에 끝나는 일에는 작은 회전 표시면 충분하지만, 사진을 올리는 것처럼 시간이 걸리는 일에는 진행 정도를 보여 주는 막대가 더 안심이 됩니다.
사용자가 지금 기다려야 하는지, 다른 일을 해도 되는지 알 수 있어야 하기 때문입니다.

 

요즘 스마트폰 앱을 기획하다 보면 터치, 길게 누르기, 쓸어 넘기기 같은 동작이 선택지로 늘어납니다.
새로운 제스처를 넣고 싶은 마음이 들 때도 있어요.
하지만 사용자가 이미 다른 앱에서 익힌 동작과 어긋나면 배우는 비용이 생깁니다.

제가 정한 원칙은 두 가지입니다.
첫째, 핵심 기능은 눈에 보이는 버튼으로도 할 수 있게 둡니다.
둘째, 숨은 제스처는 있으면 편한 보조 수단으로만 씁니다.

예를 들어 목록에서 항목을 옆으로 밀어 삭제할 수 있게 하더라도, 상세 화면에는 삭제 버튼을 따로 두는 식입니다.
제스처를 모르는 사용자가 기능을 영영 못 찾는 상황을 피하려는 거예요.

또 하나 챙기는 것은 실수로 눌렀을 때 되돌릴 방법입니다.
손가락으로 하는 동작은 마우스 클릭보다 의도하지 않은 입력이 많이 생기더라고요.
그래서 삭제처럼 되돌리기 어려운 동작에는 한 번 더 확인을 받거나, 삭제 직후 잠깐 취소할 수 있는 안내를 두는 방법을 고려합니다.
다만 확인 창이 너무 자주 뜨면 사용자가 내용을 읽지 않고 넘기게 되니, 정말 되돌리기 어려운 일에만 쓰는 편이 좋겠습니다.

 

에러 문구를 쓰다 보면 시스템 입장의 말이 되기 쉽습니다.
"잘못된 요청입니다" 같은 문장은 사용자에게 아무 도움이 안 되더라고요.

좋은 에러 안내에는 세 가지가 들어 있다고 봅니다.

• 무슨 일이 일어났는지
• 사용자의 잘못인지, 서비스의 문제인지
• 지금 무엇을 하면 되는지

가정해 보면 회원가입에서 이메일 형식이 틀렸을 때입니다.
입력 칸을 모두 지우고 처음부터 다시 쓰게 하면 사용자는 쉽게 포기합니다.
틀린 칸에만 표시를 하고, "이메일 형식을 확인해 주세요"라고 옆에서 알려 주는 편이 훨씬 낫습니다.
이미 입력한 다른 내용은 그대로 남겨 두는 것도 중요합니다.

 

인터랙션 설계는 화려한 효과를 넣는 일보다, 사용자가 어디까지 진행됐는지 항상 알게 해 주는 일에 가깝다고 느낍니다.
입력에는 반드시 반응이 있고, 그 반응이 타이밍과 문구까지 포함해 기획서에 적혀 있어야 해요.

아직 잘 모르겠는 부분도 있습니다.
반응을 하나하나 정의하다 보면 기획서가 지나치게 두꺼워지는데, 어디까지를 문서로 남기고 어디부터를 디자이너와 개발자의 판단에 맡길지가 고민입니다.
앞으로 작은 화면 하나를 골라 이 세 칸 표를 실제로 채워 보면서 감을 잡아 보려고 해요.