UX/UI의 10가지 심리학 법칙 - 존 야블로스키 을 읽고

디자이너를 타겟팅한 책이지만 개발자 역시 얻어간게 있는 책이었다. 특히 프론트개발자와 디자이너없이 개인프로젝트를 할 개발자에겐 말할 것도 없다. 책 볼륨도 크지 않아 부담없이 읽었다.

총 12장이고 이중 1-10장이 심리학 법칙이다. 이중 인상깊었던 (대부분의)법칙에 대해 써본다.

 

1. 제이콥의 법칙

유저는 당신의 사이트도 유저가 알고있는 다른 사이트와 유사하게 동작하길 원한다. 

디자이너없이 프로젝트를 하는 대부분 개발자들은 다른 사이트들을 참조하거나 클론해 디자인을 짤 것이다. 이 법칙을 생각안했더라도 서비스 품질을 높이기위해 폼에서 어떤 input type을 쓸 것인지, hover나 focus될때 어떤 변화가 발생하는지, 어떤 레이아웃과 태그를 채택해야하는지 다른 사이트를 통해 배운 경험이 있을 것이다. 

난 이 법칙을 듣고 프로젝트속 코드가 생각났다. 비슷한 performance여도 어떤 task를 수행하기 위해 작성될 수 있는 코드, 아키텍쳐, 패턴의 형태는 무궁무진하다. 개인프로젝트할때도 프레임워크와 라이브러리의 코드 권장사항을 지키고 여러곳에서 레퍼런스를 삼아 다른 프로젝트와 유사한 형태로 나의 이슈와 로직을 구현하면 디버깅을 할때나 기능을 확장할 때 생산성이 올라갔다. docs나 내가 요구하는 것의 레퍼런스를 볼 때 이해하는 속도가 올라가기때문이다.

협업할때도 중요하다. 아키텍쳐, 컨벤션등을 협의할때 피곤함을 줄이고 실수나 미처 협의되지 않은 것으로 인해 차이나는 코드가 나와도 이를 복구하는데 드는 비용이 줄어들 수 있다. 

 

3. 힉의 법칙

선택지의 개수와 복잡성이 늘어날수록 의사결정의 부담이 커진다.

내가 서비스를 이용하며 자주 겪은 경험이다. 하지만, 복잡한 선택지가 불가피할때도 있고 너무 단순화하는 기획이면 오히려 경험을 악화시킬수도 있다. 이걸 해결하기위해 선택지를 프로세스 단계별로 나누거나, 카테고리별로 분리해서 부담을 줄일 수 있겠다.

또한 기획의도나 유저행동을 추적해 추천선택지를 강조하고 앞에 배치하는 방식도 고민해 볼 수 있다.

 

4. 밀러의 법칙

일반적인 사람은 작업기억에 5~9개의 항목들까지 밖에 저장 못한다.

이 법칙 역시도 코드가 연상됐다. 이 법칙은 대략적인 범위를 알려줘서 정량적으로 깨끗한 코드와 아키텍쳐를 짤 수 있을 것 같다.

한 파일안에 여러 비즈니스로직과 태그,컴포넌트가 존재할 때 우리는 혼란스럽다.

그렇다고 어떤 비즈니스로직을  분리하고, 컴포넌트화시킬 때 너무 자잘한 레벨까지 나누다보면 그만큼 파일생성하는게 피곤하기도하지만 아키텍쳐가 과도하게 deep해지거나 width해질 수 있다.

예를들어, user.type.ts를 찾을때 /type 폴더에 수백개의 .type.ts가 있을때 또는 src/util/data/....../user/types/user.type.ts 경로에 있는걸 상상해본다면...

따라서 대략 7(7+-2)이라는 수치를 생각하면서 나눈다면(숫자에 매몰되지 않고 도메인별로 나누는것도 중요하다) 심리학적으로 피로를 덜 느끼는 깨끗한 프로젝트를 만들 수 있을 것 같다. 

 

6. 피크엔드 법칙

사용자는 여정중 가장 강렬한 순간들과 마지막에 느낀 감정을 가장 잘 기억한다.

사람 심리상 부정적인 순간이 강렬하게 느껴진다고 한다. 나름 오류 케이스 처리한다고 고민해본 적이 있는데 부족함을 느꼈다.

서비스에서 부정적인것을 덜 부정적이게 만들고 어쩌면 그걸 긍정적인 경험으로 만드는 것은 너무 중요하다 생각한다.

사용자의 행동과 서비스는 완벽하지 않기에 수많은 오류를 마주한다. 단순히 4xx상태코드를 받아도 에러메시지를 띄워주는게 아니라, 재밌는 인터렉션과 ui를 어떻게 줘야할지 고민해봐야겠다.(참고로 깃헙oauth2를 이용하면서 깃헙의 오류페이지를 상당히 많이봤는데 예시로 나와있어 반가웠다.)

어떤 여정을 성공적으로 마쳐도, 그 순간의 감정을 극대화하기 위한 인터렉션예시도 인상깊었다. 난 사실 별 신경안썻는데, 다른 유저들을 생각하며 앞으로의 개인프로젝트들에 참고해야겠다.

 

8. 폰 레스토프 효과 

비슷한 사물이 여러개 있으면 그중 차이가 나는 하나만 기억할 가능성이 크다.

난 개발할때 통일성있는 ui를 선호했는데, 너무 그것에 매몰되기보단 기획의도나 유저경험상 강조를 하고싶으면 해당장에 있는 예시를 참고할 것이다. 이 책에선 언급되지 않았으나 가끔 의도치않은 강조가 있겠다고 생각한다. 예를들면 특정 선택지만 글자개수가 특히 많거나 적다면, 특이하게 보일 수도 있단 것이다. 의도치않은 강조를 방지해야한다면, 폰트사이즈를 조정하거나 min width,min height를 주는 태크닉이 필요할 것 같다. 버그로 인해 글자레이아웃이 의도치않게 보일때도 이런 의도치않은 강조가 나올 수 있어 개발할 때 신경을 써야할 것 같다. 

 

9. 테슬러의 법칙

모든 시스템엔 더 줄일 수 없는 일정수준의 복잡성이 존재한다.

이 장을 읽으면서 디자인이 잘 돼있더라도, 한계가 있고 기술적인 방면에서 복잡성을 개선할 수 있다는 내용이라 동기부여가 됐다.

복잡성이 있을 수 밖에 없는 상황에서 기술을 이용해 이전 유저행동을 참고하거나, 기획의도나 다른 유저들의 행동에 맞게 그 상황을 일부 자동화한다면 복잡성은 줄어들 것이다. 나도 이런 디자인 복잡성의 한계가 존재할때 이를 기술로서 개선해보는 개발을 하면 재밌을 것 같다.

 

10. 도히티 임계

사용자경험(생산성)을 위해 0.4초내로 인터렉션 할 것.

LightHouse와 performance insight를 이용해 LCP와 FCP 병목을 최대한 해결해본 경험이 있다. 

페이지 이동이나 데이터를 불러올 시 버벅거린다면 이는 불편함을 유발하고 서비스를 이탈하는 계기가 된다. 나 역시도 로딩이 넘 오래걸리면(정량적으로 따지면 단순 몇초 단위지만) 이탈해본 경험이 있다.

저기선 0.4초라고 했지만, 요즘 잘 만든 서비스들이 워낙많아 커트라인이 0.4초보다 더 빠른 것 같기도 하다.(책이 비교적 최근에 나왔으나, 개발자입장이라 다른것일수도 있다.)

만약 병목을 해결하기 어려운경우 로딩프로세스를 보여주는 ui나 skeleton을 이용하는 테크닉도 이용해볼 수 있겠다. 인스타그램같이 낙관적 ui을 사용하기도한다. 이는 내가 아직 제대로 구현안한 것이라 앞으로 필요하다면 채택해야겠다. 

특이한건, 일부러 인터랙션시간을 늘린경우다. 무조건 빠르다면 신뢰성이 떨어질 수도 있는 것이다. 인터렉션이 너무 빠르다면 유저는 무슨일이 일어난건지 놓칠수도 있고, 어쩌면 인터랙션이 제대로 동작하지 않았다고 판단할 수도 있다.

예를들어 진단이나 결제프로세스에선, 신뢰성을 위해 일부러 인터렉션시간을 늘리고 각 과정을 유저에게 알려 신뢰성을 알리기도 한다

난 무조건 빠른 성능을 생각해서 신경쓰지 못했던 것인데 인사이트가 넓어졌다.