/
UX Laws

UX Laws

Source: https://99designs.com/notify-Samsung?aHR0cHM6Ly85OWRlc2lnbnMuY29tL2Rlc2lnbmVyLWJsb2cvMjAxNC8wMS8xNS83LXVuYnJlYWthYmxlLWxhd3Mtb2YtdXNlci1pbnRlcmZhY2UtZGVzaWduLw==

https://brunch.co.kr/@five0203/2

 

1. 명확성의 법칙(Law of clarity)

  1.1 Icon(버튼)이 불명확한 경우에는 명확한 Lable을 사용한다.

    예) [Dexter] Dismiss / Undismiss

         [PLATZ] 이메일 수신거부 아이콘, 왼쪽 패키지 뷰 내의 아이콘들

  1.2 하나의 버튼은 하나의 기능만 수행한다.

    예) [Dexter] Admin 기능 아이콘

 

2. 우선순위의 법칙(Law of preferred action)

  2.1 한 화면에서 사용자의 참여가 필요한 기능은 한 가지를 강조한다.

    예) [Dexter] 결함 목록 화면(웹)

         [PLATZ] Add Question 아이콘, Tizen API 검색 입력 창 등

  2.2 한 화면에서 우선순위가 떨어지는 기능을 강조하지 않는다.

    예) [Dexter] 결함 목록 화면(웹)

 

3. 문맥의 법칙

  3.1 사용자의 행위나 사고의 순서대로 입력창, 버튼 등을 배치한다.

    예) [PLATZ] 공지 작성 화면내의 컬럼들의 순서

 

4. 기본 설정의 법칙(Law of defaults)

  4.1 기본 설정 아이콘을 다른 용도로 사용하지 않는다.

    예) [PLATZ] 이메일 아이콘을 메일 수신설정으로 사용

 

5. 유도의 법칙(Law of guided action)

  5.1 사용자의 행위나 참여가 필요한 경우 요청 대화상자를 통해 진행한다.

    예) [Dexter] 체커 설명을 추가적으로 볼지 여부

         [PLATZ] 패키지 레벨에서 수신 거부상태에서 일부 API를 수신하고자 하면 패키지 수신거부 해제 여부를 묻기

 

6. 피드백의 법칙(Law of feedback)

  6.1 데이터베이스에서 CUD가 발생할때에는 반드시 팝업, 로그 등을 활용하여 사용자에게 처리 결과를 알린다.

    예) [PLATZ] 공지 메일 송부 후에 송부가 완료되었음을 알림(수초후 자동 숨김 팝업창)

 

7. 간편함의 법칙(Law of easing)

  7.1 사용자의 입력이 많이 필요한 경우 Step 별로 화면을 구성한다.

    예) [PLATZ] API 변경 공지화면