UI, UX 얼핏들어서는 그냥 사용자에게 깔끔하게 보여지고 페이지가 간단한 구조를 가지고 있는 것을 말하는 것같다.
더 안으로 들어가보자.
User Interface, 사용자 인터페이스. 사람들이 컴퓨터와 상호 작용하는 시스템.
UI는 사용자가 시스템의 기능을 이해하고 조작할 수 있도록 도와주는 시각적, 청각적 등등 다양한 형태의 구성요소로 이뤄져 있다.
화면이외에도 키보드, 마우스, 등의 물리적 요소도 컴퓨터와 상호 작용하기 위한 시스템이기 때문에 UI이다.
요즘은 화면에서 소통하는 것이 많다. CLI(Command Line Interface)로 모든 것을 할 수 있었지만, 사용자가 사용하기에는 알아야 할것도 많고, 직관적으로 보이지도 않아서 서로 상호작용하는 데에 진입장벽이 높았다.
하지만 요즘에는 스마트폰, 컴퓨터, 키오스크 등등 많은 것을 그래픽으로 상호작용을 한다. 복잡한 CLI보다는 사용하기 직관적이고 간편한 GUI(Graphic User Interface)가 중요한 역할을 한다.
User Experience, 사용자 경험. 사용자가 제품, 서비스 또는 시스템과 상호 작용하는 동안 느끼는 모든 경험을 의미한다. UX는 사용자가 제품을 사용하는 동안 느끼는 만족도, 유용성, 편의성, 효율성, 접근성 등을 포괄한다.
그렇기 때문에 사용자의 감정, 인식, 선호도, 피로감, 효율성 등 다양한 측면은 고려해서 디자인을 설계해야 한다.
UI와 UX의 차이점 보다는 UX(사용자 경험)가 UI(사용자 인터페이스)를 포괄하는 개념이다.
UX는 사용자 인터페이스(UI) 디자인뿐만 아니라 제품의 기능, 성능, 내비게이션, 정보 구조, 텍스트 및 그래픽 등 모든 측면을 다루는 디자인 접근법이다.
UX가 좋다고 해서 UI까지 좋은 건 아니다. 하지만 좋지 않은 UI는 좋지 않은 UX를 유발한다.
UX의 좋지 않은 점을 찾으면 UI의 개선점을 찾을 수 있고, UI를 개선하면 UX도 개선이 된다
문제점을 계속 해결해온 결과물을 재사용하기 좋은 형태로 만든 패턴을 말한다.
자주 쓰이는 디자인 패턴을 UI 디자인 패턴을 익혀두면 디자인하기가 보다 쉬워지고, 프론트엔드 개발자, 디자이너, PM 과의 의사소통도 원횔해져 협업 효율도 높아진다.
- 모달(Modal): 화면 위에 오버레이되는 창. 또 다른 페이지를 여는 팝업창과는 다르다.
- 토글(Toggle): 시각적 효과를 주어 사용자가 토글의 상태를 직관적으로 알게 해준다. 옵션이 많다면 토글보다는 탭 사용 고려한다.
- 탭(Tab): 콘텐츠를 분리해서 보여주고 싶을 때 사용한다. 탭의 이름은 간결해야하며 분리된 섹션의 구분이 명확해야하며 어떤 탭이 지금 보여지고 있는 상태인지도 표시해주어야 한다.
- 태그(Tag): 태그는 콘텐츠를 설명하는 키워드를 사용해서 라벨을 붙이는 역할을 한다. 이 태그로 콘텐츠를 필터할 수 있다. 추가와 제거가 쉽고 자유롭게 되어야 한다.
- 자동완성(Autocomplete): 사용자가 내용을 입력할 때, 사용자가 검색할 내용과 일치할 가능성이 높은 항목을 보여준다.
- 드롭다운(Dropdown): 선택할 수 있는 항목들을 숨겨놓았다가 펼쳐서 선택할 수 있게 한다.
- 아코디언(Accordion): 접었다 폈다 할 수 있는 컴포넌트.
- 캐러샐(Carousel): 콘텐츠들을 옆으로 넘기는 컴포넌트. 자동으로 넘어가거나 사용자가 직접 넘길 수 있도록 만들어야 한다. 아님 둘다. 이때는 사용자가 직접 넘길 수 있는 것인지 자동으로 넘어가는 것인지 직관적으로 알게 만들어야 한다.
- 페이지네이션(Pagination): 한 페이지에 띄우기 너무 많은 정보가 있다면 페이지를 구분해서 정보량을 제한해서 보여줄 수 있다.
- 무한 스크롤(Infinite Scroll): 페이지네이션과 마찬가지로 정보가 많다면 초기에는 일부만 보여주고 스크롤을 통해 다음 정보를 탐색할 수 있게 만드는 컴포넌트. 처음부터 모든 정보를 불러와서 스크롤을 통해 보여주는 것이 아니라 보통 페이지 맨 아래 도달하게 되면 조금씩 보여주는 방식.
- GNB(Global Navigation Bar): 어느 페이지에서도 사용가능한 최상위 메뉴바. 항상 동일한 위치에 있어야 하며, 여기서도 탭을 이용하여 GNB에 종속되는 서브 메뉴인 LNB(Local Navigation Bar)를 드롭다운 방식을 이용해서 보여줄 수 있다.
피터 모빌이 좋은 UX를 만드는 요소를 7가지로 제시했다. 벌집 모형(Honey Comb).
이 모형을 통해 각 요소를 개선하면서 가치를 높일 수 있다.
- 유용성(Useful)
목적에 맞는 기능을 하나?- 사용성(Usable)
본연의 기능을 제공하는 것을 넘어 사용하기 쉬운가?- 매력성(Desirable)
디자인이 보기 좋은지부터 이미지, 브랜딩 등의 여러 요소들이 사용자에게 긍정적인 감정을 불러 일으킬 수 있는지?- 신뢰성(Credible)
사용자가 제품이나 서비스를 믿고 사용할 수 있는가? 직접적인 서비스 이외에도 사용자의 편의를 생각한 디테일이 있다면 신뢰성을 올릴 수 있다.- 접근성(Accessible)
누구든지 모두가 제품이나 서비스에 접근할 수 있는가? 누구나 비슷한 정보를 얻을 수 있게 만드는가?- 검색 가능성(Findable)
사용자가 원하는 기능이나 정보를 얼마만큼 쉽게 찾을 수 있는가? 그에 대한 예시로 네비게이션 바를 예로 들 수 있겠다.- 가치성(Valuable)
위 모든 요소들을 총합하여 사용자가 이걸 사용할 가치가 있다고 생각하는가?
이러한 사용자 경험(UX)를 위해서는 개발자 입장에서는 어떻게 설계를 시작할까?
설계를 깔끔하게 하기 위해 사용하는 것이 있다. User Flow 다이어그램.
보통 이 다이어그램을 그릴 때, 기본적으로 3 요소를 활용한다.
머리로만 사용자 흐름을 예측하는 것보다. 청사진을 다이어그램을 그려서 사용자 흐름을 빈틈없이, 보다 편리하게 다듬어가기 직관적이고 편하다.
제이콥 닐슨의 10가지 사용성 평가 기준 (Jakob's Ten Usability Heuristic)
직관과 경험을 활용하는 방법론이다.
- 시스템 상태의 가시성(Visibility of system status)
무슨 일이 일어나는지 디자인은 계속해서 합리적인 시간안에 적절한 피드백을 통해서 유저에게 정보를 줘야 한다.- 시스템과 실제 세계의 일치(Match between system and the real world)
시스템은 사용자에게 익숙한 언어, 개념 및 관습을 사용해야 한다. 이를 통해 사용자는 시스템을 이해하고 상호 작용하기 쉬워진다.- 사용자의 제어와 자유(User control and Freedom)
사용자는 실수를 할 수 있기 때문에 실행한 동작을 되돌릴 수 있는 기능이 제공되어야 한다. 또한, 사용자에게 자유를 주어 사용자는 시스템을 탐색하고 조작하는 데 자유롭게 사용해야 한다.- 일관성과 표준화(Consistency and standards)
시스템은 일관된 방식으로 작동해야 한다. 업계의 관습을 따른다. 사용자는 예측 가능하고 일관된 경험을 할 수 있어야 한다.- 오류 예방(Error prevention)
좋은 에러 메세지도 좋지만 애초에 에러를 안나게 막는 것이 더 좋은 디자인이다. 어떤 실행을 하기 전에 사용자에게 한번 더 확인 옵션을 제공하는 것이 예시가 될 것이다.- 기억보다는 재인식(Recognition rather than recall)
사용자들이 기억하는 것보다는 인식하는 것이 편의성을 더 제공한다. 사용자의 메모리를 사용하기 보다 컴퓨터의 메모리를 사용하여 가시적으로 보여줘야 한다.- 유연하고 효율적인 사용자 인터페이스(Flexibility and efficiency of use)
초보자와 숙련자 둘 다 쉽게 사용할 수 있게 해야한다. 초보자는 아직 익숙하지 않지만, 숙련자에게 Shortcuts을 제공해서 개별적이고 효율적으로 사용하게 한다.- 미학적이고 미니멀한 디자인(Aesthetic and minimalist design)
인터페이스에는 관련없거나 필요없는 정보들을 포함하지 않아야 한다.- 오류의 인식, 진단, 복구를 지원(Help users recognize, diagnose, and recover from errors)
에러메세지는 명백하고 간결하게 문제가 무엇인지 표현하고 에러에 대한 해결책까지 제안해야 한다.- 도움말과 문서(Help and documentation)
시스템에 추가설명이 필요하지 않으면 좋겠지만 사용자가 그들의 임무를 어떻게 완료하는 지에 대한 이해하는 것을 돕기위해 문서를 제공하는 것은 필요하다.
보기좋은 떡이 먹기도 좋다. 눈에도 좋고 맛도 좋다. 사용자 입장에서 계속해서 생각해봐야겠다.
이거 보기 좋나? 이거 하면 불편한 점은 없을까? 개발은 뭔가를 만들어서 사용자에게 서비스를 주는 공급자 역할이라는 것이 다시 상기되었다.