평소 보는 아티클에서 모집한 스터디에 신청해 휴리스틱을 바탕으로 사용성 개선 프로젝트를 시작했다.
스터디 과제를 준비하면서 정리하고 알게된 부분들을 티스토리에도 남겨둔다.
원문_
www.nngroup.com/articles/ten-usability-heuristics/
휴리스틱?
They are called "heuristics" because they are broad rules of thumb and not specific usability guidelines.
특정한 사용성 가이드라인을 위한 것만이 아닌, 경험에 근거한 규칙 으로, 보다 광범위한 규칙에 해당하기 때문에 "휴리스틱"이라 부른다.
1. 시스템 상태 가시성 확보
The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.
디자인은 항상 적절한 시간 내 피드백을 통해 사용자들에게 지금 무엇이 일어나고있는지 알려줘야합니다.
어떤 액션이 일어나거나, 단계에 있어 사용자들에게 계속해서 현재 상태가 어떤지, 왜 이 일이 일어나는지 알려주어야 한다. 단, 알람이나 팝업, 혹은 빨간 색상을 사용해 보여주어야 하는 것만은 아니다. 또 "reasonable amount of time" 이 들어간 것으로 보아 해당 피드백이 나타나는 시간 또한 중요하다. 피드백은 즉시 보여져야 사용자의 혼란을 막을 수 있기 때문이다.
2. 실제 세상과 시스템 간 어울림
The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon. Follow real-world conventions, making information appear in a natural and logical order.
디자인은 사용자의 언어로 말해야합니다. 사용자에게 친숙한 단어, 절, 컨셉을 사용해야하며 내부인만 알 전문용어는 쓰지 마세요. 실제 세상의 관습을 따르고, 자연스럽고 논리적인 순서에 따라 정보가 나타나게 하세요.
앱에서 나오는 단어를 사전에서 찾아보는 것은 말도 안되는 일! 또 사용자의 언어 이해도를 추측해서도 안된다. 이를 방지하기 위해선 역시 유저 리서치를 통해 직접 만나보는 것이 중요하다.
3. 유저 컨트롤과 자유도
Users often perform actions by mistake. They need a clearly marked "emergency exit" to leave the unwanted action without having to go through an extended process.
사용자는 실수로 액션을 취하기도 합니다. 이러한 원치않은 액션을 더이상 진행하지 않고도 떠나기 위해선 정확히 명시된 "비상 출구"가 필요합니다.
실행취소와 다시 실행 기능이 필요하다. 이러한 버튼은 확실히 보이게 해야한다. 서비스의 BM 특성상 이런 것들을 빼는 경우도 있..나..? 예전엔 있어도 이젠 없는 듯 하다.
4. 지속성과 표준
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.
사용자들은 다른 단어, 상황, 액션이 서로 같은것인지 고민해야할 필요가 없습니다. 플랫폼과 산업의 관습을 따르세요.
5. 오류발생 방지
Good error messages are important, but the best designs carefully prevent problems from occurring in the first place. Either eliminate error-prone conditions, or check for them and present users with a confirmation option before they commit to the action.
좋은 오류 메세지는 중요하지만, 애초에 이러한 문제가 발생하지 않도록 주의깊게 디자인하는 것이 더 중요합니다. 오류 발생이 쉬운 조건을 삭제하거나, 미리 확인하고, 사용자들이 액션을 취하기 전에 확인 옵션을 보여주세요.
두가지 종류의 에러 : 슬립/실수. 슬립은 주의를 기울이지 않아서 무의식중에 발생하는 것, 실수는 의식상태에서 발생하는데, 사용자의 생각과 디자인이 불일치해서 잘못된 결과를 내는 것.
그렇다면 슬립과 실수를 어떻게 구분할 수 있을까? 아주아주 짧은 시간동안 (at a glance) 잘못 생각해 잘못 누르는 경우가 있다. 이 경우는 실수인가?
슬립과 실수를 방지하는 법. 슬립 방지하기: 제한, 통제를 걸어두기. 좋은 예시의 디폴트 만들어두기. / 실수 방지하기 : 기억해야만 하는 짐 덜기(너무 많은 것을 기억하게 하지 말기), 실행취소와 경고 지원하기.
6. 기억하기 대신 알아채기
Minimize the user's memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another. Information required to use the design (e.g. field labels or menu items) should be visible or easily retrievable when needed.
사용자의 기억력 사용을 최소화 하세요. 볼 수 있는 엘리먼트와 액션, 옵션을 사용할 수 있습니다. 사용자들은 화면 한쪽의 정보를 다른 쪽에서 볼때까지 기억할 필요 없습니다. 필드 라벨이나 메뉴 아이템 등 요구되는 정보들은 볼 수 있거나, 필요할 때 다시 볼 수 있어야 합니다.
사용자의 기억력을 믿어선 안되고, 기대해서도 안된다. 특히 뭔가를 입력하는 창 (구매하거나 가입하는 등)이 여러 단계로 나눠져있으면 해당 내용을 다시 보거나 수정하려고 할때 어려움을 자주 겪었다. 그러나 이는 긴 튜토리얼로 해결될 것이 아니라, 화면 엘리먼트에서 해결되어야 한다.
7. 사용의 유동성과 효율성
Shortcuts — hidden from novice users — may speed up the interaction for the expert user such that the design can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
(초보 사용자에게는 숨겨진) 지름길은 전문 사용자에게 상호작용의 속도를 높이며, 경험이 없는 사용자와 경험이 있는 사용자 모두를 만족시킬 수 있습니다. 자주 사용하는 기능을 사용자에게 맞춰 조정할 수 있도록 하세요.
키보드 쇼트컷과 터치 제스처 활용 기능 활용한다. 커스텀 기능을 제공한다. 예시가 마땅히 떠오르지 않는다. 위젯도 일종의 쇼트컷인가?
8. 진실되고 미니멀한 디자인
Interfaces should not contain information which is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility.
인터페이스는 불필요하거나 거의 필요하지 않은 정보를 포함하지 말아야 합니다. 화면 위에 띄워진 여분 정보들은 중요한 정보와 경쟁하고, 중요한 정보를의 가시성을 낮춥니다.
플랫디자인을 하라는 뜻이 아니라, 콘텐츠와 시각 디자인이 정말 중요한 것에 초점이 맞춰져있는지 끊임없이 생각하라는 뜻. 모든 정보들은 나 봐주세요! 와 하는 위치가 아니라 사용자의 '가장 중요한 목표'를 달성하기 위한 수단들이다. 불필요한 정보가 있으면 자리를 차지할 뿐만 아니라, 진짜 필요한 정보로부터 사용자를 방해한다. 가장 중요한 목표가 무엇인지 생각.
9. 사용자가 에러를 인지하고, 진단하고, 복구하도록 돕기
Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.
에러(오류) 메세지는 이해하기 쉬운 언어로 표현되어야 합니다. (에러코드 금지) 간결하게 문제를 알리고, 건설적으로 해결책을 제시해야합니다.
전통적인 에러 베세지 : 볼드, 붉은색 텍스트. 문제를 즉각 해결할 수 있는 지름길과 같은 해결책을 알려주어야 한다.
그러나 새로고침이나 앱 강제종료 외에는 똑똑한 해결책을 제안받은 적이 없다... 기억이 안난다. 그리고 디자인 할 때도 마찬가지, 에러화면을 디자인한 적이 있었나..? 하하.
10. 도움말 및 문서
It’s best if the system doesn’t need any additional explanation. However, it may be necessary to provide documentation to help users understand how to complete their tasks.
시스템에서 어떤 추가적인 설명도 필요하지 않은 것이 제일 좋겠지만, 사용자가 어떻게 그들의 목표를 달성할 수 있을지 이해시키는 문서가 필요할 수 있습니다.
문서는 검색하기 쉽게! 수행할 수 있는 단계를 제시하는 것이 좋다. 어떤 문제가 있을 때, 단계별로 있으면 참 알기 좋다. 뭔가를 해결해내는 (실제 세상에서의) 경험과 일치하며, 목적이 달성되고있다는 인식을 줄 수 있기 때문이다.
'Drafts' 카테고리의 다른 글
경제주간지 기록_4월 3주차 (0) | 2021.04.14 |
---|---|
교보문고 앱 분석 (0) | 2021.04.11 |
경제주간지 기록_4월 2주차 (0) | 2021.04.08 |
쿠팡이츠 앱 분석 (1) (0) | 2021.04.02 |
앱 텍스트 색상에 #000000 검정을 쓰지 않는 이유 (0) | 2021.02.18 |