▲

관용적 디자인을 되살리자

 (essays.johnloeber.com)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 사용자에게 즉각적으로 이해되는 디자인 관용구는 학습 부담을 줄이고 일관된 상호작용을 가능하게 함
  • 과거 데스크톱 소프트웨어 시대에는 운영체제와 가이드라인 덕분에 메뉴 구조와 단축키 등 인터페이스가 통일되어 있었음
  • 반면 브라우저 기반 소프트웨어 시대에는 프레임워크와 커스텀 구현 확산으로 인터페이스의 일관성이 붕괴됨
  • Apple과 Substack은 제한된 커스터마이징과 통일된 디자인 시스템으로 현대적 관용구의 성공 사례를 보여줌
  • 제품 설계자는 기존 관용구를 따르고, 명확성과 일관성을 우선시해 웹 전반의 표준화된 사용자 경험으로 나아가야 함

디자인 관용구

  • 체크박스는 사용자가 별도의 학습 없이 즉시 이해할 수 있는 대표적 디자인 관용구로 제시됨
    • 로그인 유지 여부를 묻는 질문에 다양한 입력 방식이 가능하지만, 실제로는 항상 체크박스가 사용됨
    • 이는 사용자와 개발자 모두에게 익숙한 표준화된 상호작용 패턴으로 작동

균질한 인터페이스

  • 인터페이스는 사용자가 시스템과 상호작용하는 수단이며, 생각할 필요가 적을수록 좋은 인터페이스로 평가됨
    • 예를 들어, Command+C 단축키로 복사하는 기능은 어디서나 동일하게 작동해야 함
  • 그러나 현재의 웹 소프트웨어 환경에서는 인터페이스의 일관성이 사라짐
    • 날짜 선택, 카드 번호 입력 등 기본 기능조차 사이트마다 다르게 구현되어 있음
    • 단축키와 상호작용 방식이 앱마다 달라 사용자는 매번 “어디서 무엇을 눌러야 하는가”를 다시 학습해야 하는 상황

데스크톱 소프트웨어 시대

  • Windows 95~7 시기의 데스크톱 소프트웨어는 높은 인터페이스 일관성을 유지
    • “File, Edit, View” 메뉴 구조가 모든 프로그램에서 동일하게 존재
    • 메뉴 항목의 밑줄은 키보드 단축키를 의미하며, ALT+F, N 등으로 조작 가능
    • 하단의 상태 표시줄(status bar) 은 현재 상태(페이지, 단어 수, 모드 등)를 명확히 표시
    • 텍스트 기반 메뉴 중심으로, 아이콘은 명확한 의미를 가질 때만 사용
  • 이러한 관용구는 Microsoft Word뿐 아니라 Windows 전체 생태계에 걸쳐 통일되어 있었음
    • Windows XP의 로그아웃 화면에서도 모든 버튼이 명확히 버튼임을 시각적으로 표현하고, 단축키가 표시됨
  • 이러한 일관성은 운영체제와 GUI 라이브러리의 제약 덕분에 가능했으며, Microsoft는 수백 페이지의 디자인 가이드라인을 배포해 개발자들이 이를 따르도록 유도

브라우저 소프트웨어 시대

  • 현재의 웹 애플리케이션 시대는 이질적 인터페이스의 시대로 묘사됨
    • Figma와 Linear 같은 우수한 웹앱조차 공통 아이콘이나 단축키가 없음
    • 각 앱이 독자적으로 잘 설계되었지만, 서로 다른 상호작용 패턴을 가짐
    • 동일 회사 내에서도 Gmail, GSuite, Google Docs의 경험이 서로 다름
    • 결과적으로 사용자는 생산적 흐름(flow) 대신 조작 위치를 탐색하는 시간을 보내게 됨

  • 모바일 전환의 영향

    • 터치스크린 등장으로 마우스·키보드 중심의 디자인 패턴이 재발명됨
    • 모바일과 데스크톱을 동시에 지원해야 하는 상황에서 중간 형태의 불완전한 UI가 확산
    • 예: 모바일용 햄버거 메뉴가 데스크톱에서도 그대로 사용되는 사례
    • 모듈형 컴포넌트 재사용 문화가 잘못된 패턴을 복제하며 품질 저하를 초래
    • 10년 이상 누적된 결과로 UI/UX 품질의 세대적 침식 발생

  • HTML을 넘어선 관용구의 부족

    • 초기 웹에서는 파란색 밑줄 링크 등 명확한 관용구가 존재했으나, 현재는 사이트마다 스타일이 제각각
    • HTML/CSS 표준은 엄격하지만, 실제로는 대부분 React·TypeScript 기반 빌드 시스템을 사용
    • 결과적으로 표준 HTML 요소 대신 커스텀 구현이 난무하며 접근성 문제까지 초래
    • 예: <a> 대신 onclick이 달린 <span> 사용으로 스크린리더 기능이 깨짐
    • Figma처럼 WebAssembly 기반으로 HTML을 완전히 벗어난 앱도 존재
    • 브라우저의 뒤로가기 버튼, 단축키 등 기본 기능이 무시되며, 새로운 인간-컴퓨터 상호작용 패러다임이 재구성됨
    • 프런트엔드 개발이 속도와 가능성 중심으로 발전하면서, 일관된 관용구 정착이 어려움
    • 수많은 프레임워크와 상호작용 형식이 존재해 단일 표준 확립이 구조적으로 어려운 환경

관용적 디자인의 성공 사례

  • Apple은 현대에 강력한 디자인 관용구를 유지하는 대표 사례로 꼽힘
    • 폰트, 버튼, 색상 등 전반적 디자인 시스템이 통일되어 있으며, iOS 전반의 일관된 상호작용 경험을 제공
    • 이러한 일관성이 “it just works”라는 신뢰감을 형성
  • Substack 또한 제한된 커스터마이징과 미리 정해진 미학적 기본값을 통해 안정된 사용자 경험을 제공
    • Apple과 Substack의 디자인 원칙은 성공을 통해 업계 표준으로 확산, 결국 새로운 관용구로 자리잡음

제품 설계자가 따라야 할 원칙

  • 제품 개발자는 가능한 한 기존 디자인 관용구를 따르는 것이 사용성과 호환성을 높이는 길로 제시됨
    • HTML/CSS의 기본 관용구를 준수: 링크는 밑줄·색상·포인터 커서·<a> 태그로 구현
    • 기본 HTML 요소를 JavaScript로 재구현하지 말 것, 예: React Button 대신 <button> 사용
    • 브라우저 관용구 준수: 뒤로가기 버튼 작동, URL 복사 시 동일 인터페이스 접근, CTRL+클릭 시 새 탭 열기
    • 일반 관용구에서 벗어날 경우, 조직 내부적으로라도 일관된 규칙을 유지
    • 텍스트 우선, 아이콘 최소화, 아이콘은 보편적으로 이해 가능한 경우에만 사용
    • 시각적 요소는 명확함이 미적 아름다움보다 우선
    • 판단이 어려울 경우, 우수한 웹사이트 사례와 과거의 인터페이스 디자인 서적을 참고
  • 궁극적으로는 모든 웹의 날짜 선택기나 카드 입력 폼이 동일하게 작동하는 미래를 지향하며, 수십 년의 반복과 개선 끝에 최적의 관용구로 수렴하는 웹 환경을 목표로 제시됨

함께 보면 좋은 글 β

▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 어떤 앱에서는 Enter가 입력 전송이고 Ctrl+Enter가 줄바꿈임 (예: Slack), 또 어떤 곳은 반대임 (예: GitHub)
    이런 일관성 부족이 사용자 입장에서는 꽤 혼란스러움. “관용적 디자인을 되살리자”는 말이 있지만, 정작 공통된 관용이 부족한 게 문제임

    • 예전에는 Return과 Enter가 다른 키였음. Return은 줄바꿈, Enter는 입력 전송용이었음.
      지금은 키가 하나로 합쳐져서, 일반적으로 멀티라인 입력창에서는 Enter가 줄바꿈, Ctrl+Enter가 전송임.
      반면 채팅앱은 단문 입력이 많아서 반대로 동작함. 좋은 앱은 이걸 설정으로 바꿀 수 있게 함
    • Teams는 두 가지 모드가 있음. 기본은 Enter로 전송, Shift+Enter로 줄바꿈인데, 서식 도구를 열면 반대로 바뀜.
      어떤 조합이 줄바꿈인지 표시해주긴 하지만 여전히 헷갈림
    • Slack은 더 복잡함. Markdown을 켜면 Shift+Enter가 줄바꿈인데, 코드 블록(```) 안에서는 Enter가 줄바꿈, Shift+Enter가 전송임.
      의도는 이해하지만 사용성은 엉망임
    • 이상적인 해결책은 Ctrl+Enter는 항상 전송, Shift+Enter는 항상 줄바꿈, Enter는 상황에 따라 기본값을 따르는 식이 좋을 듯함
    • 나도 Shift+Enter가 줄바꿈이라고 생각했는데, 이처럼 파편화된 UX가 문제임을 보여줌

  • 요즘 소프트웨어는 예전처럼 사려 깊은 설계자가 만드는 게 아님.
    대신 급히 승진한 PM이나 Product 담당자가 주도하고, 수익을 위한 다크 패턴까지 장려되는 현실임

    • 모바일 엔지니어로서, 이해관계자에게 “그냥 아이디어대로 만들면 안 된다”고 말하면 멍한 표정을 많이 봄.
      UX 일관성과 정보 구조(IA)의 중요성을 강조해야 함. 디자이너도 문제 해결자임을 잊지 말아야 함
    • 이런 비판은 너무 단편적임. 실제로 온라인 폼 하나 만드는 것도 지옥임.
      예를 들어 신용카드 폼을 만들 때 복사/붙여넣기 허용 여부, 구형 브라우저 지원, 접근성과 보안의 균형 등 수많은 변수가 있음.
      참고로 Steve Yegge의 플랫폼 글도 이런 복잡성을 잘 설명함
    • 2010년대에는 숙련된 UX 디자이너들이 빠지고, 인쇄나 그래픽 출신의 비전문 디자이너가 대거 들어오면서 품질이 떨어졌음
    • 물론 나쁜 인센티브와 급한 일정도 있지만, 단순히 무능이나 악의로만 보긴 어려움. 시스템 자체가 변했음
    • 지금도 PM이 전체 아키텍처와 릴리스 로드맵까지 직접 설계하려 드는 걸 보면, 이 말이 틀리지 않다고 느낌

  • 시스템 프레임워크가 관용적 UI를 만들어주는 기반이었음.
    Win32, AppKit, UIKit은 세세한 부분까지 다뤄서 개발자가 자연스럽게 일관된 UX를 따르게 했음.
    반면 웹은 그런 게 없어서 전부 직접 구현해야 하고, 결과적으로 반쯤 완성된 UI가 많음

    • 하지만 글쓴이는 웹의 불일치를 잘못 짚었음. “데스크톱 시대”는 사실상 Windows 시대였고, Win32가 기본이었기에 다들 그걸 따랐던 것뿐임.
      웹은 처음부터 문서 중심이라 표준적 접근이 없었고, 나중에 Bootstrap 같은 게 등장하며 일시적 표준이 생겼음
    • HTML과 CSS가 있었지만, 요즘은 WebAssembly 등으로 우회함.
      사실 날짜 선택기나 카드 입력은 기본 HTML 컨트롤을 써야 함.
      그러면 브라우저가 OS 수준의 보안과 편의성을 제공할 수 있음 (예: Safari는 Apple Wallet, Android는 Google Pay 연동)
    • OS의 일관된 동작에 익숙한 개발자는 자연히 그 환경을 모방하려 함.
      하지만 웹과 모바일은 완전히 다른 상자형 환경이라 이런 일관성이 깨졌음.
      예를 들어 데스크톱의 오른쪽 클릭을 모바일의 롱프레스로 통일할 기회가 있었지만, 일관되게 추진되지 않음
    • 웹의 근본 문제는 여전히 문서 중심 패러다임에 머물러 있다는 점임.
      앱 UI를 만들려면 문서 UI 위에 덧씌워야 해서 충돌이 생김.
      브라우저가 이를 완화하긴 했지만 근본 개선은 아님
    • 참고로 AppKit에서도 버튼 높이 변경은 가능함. 단지 명확하지 않을 뿐임

  • 날짜 선택기는 정말 UX 악몽임.
    사용자가 직접 날짜를 입력하려 하면 막고, 억지로 클릭하게 만드는 경우가 많음.
    실수 입력만 잡아주면 되는데, 굳이 불편하게 만듦

    • 생일 입력하려고 수십 년치 달력을 넘기다 보면 인생의 무상함을 느끼게 됨
    • 모바일의 시간 선택기도 제각각임. 스크롤 한 번에 12:00에서 11:50으로 가기도 하고 안 가기도 함.
      아날로그 시계형 선택기가 더 직관적이라 이런 게 표준이 되면 좋겠음
    • 날짜 형식도 문제임. 03/04/2026이 3월 4일인지 4월 3일인지 헷갈림.
      국제 사용자라면 YYYY-MM-DD 형식이 안전함
    • 생일 입력할 때 미래 일정용과 같은 날짜 선택기를 쓰는 사이트는 최악임.
      50년 전으로 스크롤하게 만들고 나이만 실감나게 함
    • 생일 입력할 때마다 스크롤로 나이를 체감하게 만드는 건 고문 같음

  • 요즘 UX 품질 하락이 심함, 특히 은행 웹사이트에서 두드러짐.
    스크롤바 숨기기, 낭비된 여백, 플랫 버튼, 혼란스러운 아이콘 등으로 예전 데스크톱 UI보다 훨씬 불편해짐

    • 스크롤바를 숨기는 건 정말 이해 안 됨. 단지 “보기 좋게” 하려는 미적 이유로 보임
    • Material UI가 여러 산업에 악영향을 줬다고 느낌.
      GCP나 Google 도구들은 불필요하게 복잡하고, 상자 없는 입력창 등으로 UX를 망쳤음.
      다행히 요즘은 이런 스타일이 구식으로 여겨지고 있음

  • 예전 Mac에서 온 개념 중 하나는, 버튼 텍스트 끝에 줄임표(…) 가 있으면 추가 입력이 필요하다는 뜻임.
    반면 줄임표가 없는 버튼은 클릭 즉시 동작이 완료됨

  • “아이콘보다 단어를 선호하라”는 말에 공감함.
    대부분의 사람은 단어 인식 속도가 아이콘보다 빠름

    • 물론 실제 사물을 그린 아이콘은 괜찮지만, 요즘은 너무 추상적이고 선형적인 아이콘이 많음.
      텍스트 설명이 없으면 마치 러시안 룰렛처럼 클릭해야 의미를 알 수 있음
    • HN의 “unvote/undown”처럼 접두사가 같아 헷갈리는 경우도 있음. 클릭할 때마다 다시 확인하게 됨
    • 아이콘이 작거나 위치가 자주 바뀌면 단어가 더 낫지만, 고정된 환경에서는 아이콘이 더 빠를 수도 있음

  • 최근 CSS라는 신기술을 발견했는데, 선언적으로 레이아웃을 정의하고 DOM 기반으로 계층적 스타일을 적용할 수 있음.
    클라이언트와 서버 부하를 줄이고, 스타일시트를 공유하거나 사용자 맞춤 테마도 쉽게 만들 수 있음.
    “no-framework” UI 패러다임이라 부르고 싶음
    예시 이미지

    • 써봤는데 완전 악몽이었음. 어떤 스타일이 어디에 적용되는지 알 수 없고, DOM 구조가 바뀌면 스타일이 엉망이 됨.
      게다가 “클라이언트 부하 최소화”는 신화에 불과함. 실제로 더 느림
    • 이 아이디어는 vanilla-js 프레임워크 팀에 제안해보면 좋겠음

  • 우리가 잃어버린 공통 기능들:
    Undo/Redo, 도움말(F1), 마우스 오버 힌트, 단축키 커스터마이징, 메인 메뉴, 파일/디렉터리, ESC로 닫기, 드래그앤드롭 등
    한때 혁신적이던 기능들이 이제는 모바일과 웹에서 거의 사라졌음

  • 많은 문제는 시각 디자이너가 제품 설계로 넘어온 결과임.
    디자인 직군의 역할 혼동이 여전히 해결되지 않았고, 사실 “디자이너”가 필요 없는 프로젝트에도 너무 많이 투입되는 게 현실임

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.