UI 샌딩하기

 (blog.jim-nielsen.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • UI 완성도는 구현 직후가 아니라 실제로 계속 클릭해 보는 반복 과정에서 올라가며, 글은 이를 목공의 샌딩에 비유함
  • 페이지 전환과 내비게이션은 클릭, 브라우저 뒤로가기, 우클릭 “Back”, 앱 내 뒤로가기, 키보드 단축키처럼 여러 진입 경로로 확인해야 함
  • label과 input type="radio"를 flexbox로 정렬하고 gap을 넣자, 라디오 버튼과 라벨 사이가 클릭되지 않는 dead zone으로 드러남
  • 해결은 gap을 없애고 label에 padding을 주는 방식이었으며, 시각적 간격은 유지하면서 클릭 가능한 영역이 넓어짐
  • 작은 상호작용 결함도 쌓이면 사용 경험을 해치므로, UI를 반복해서 사용하며 “가시”가 더 이상 잡히지 않을 때까지 다듬어야 함

반복 클릭으로 UI의 거친 부분 찾기

  • UI 작업은 무언가를 만든 뒤 많이 클릭하고, 수정한 다음 다시 클릭하는 반복에 가까움
  • 페이지 전환은 한 가지 흐름만 확인해서는 부족하며, 여러 방식으로 되돌아가며 살펴봐야 함
    • 클릭 후 브라우저 뒤로가기 버튼 사용
    • 클릭 후 우클릭 컨텍스트 메뉴의 “Back” 사용
    • 앱 안의 뒤로가기 내비게이션 사용
    • 키보드 단축키로 뒤로가기 사용
  • 이 과정은 QA처럼 “클릭해서 망가뜨려 보기”에 가깝지만, 목공에서 사포질하며 거친 부분과 가시를 찾는 감각에 더 가까움
  • 소프트웨어 UI에는 너무 많은 상태와 변수가 있을 수 있어, 반복 사용으로 더 이상 “가시”가 잡히지 않을 때까지 다듬게 됨

flexbox gap이 만든 클릭 dead zone

  • 라디오 옵션 목록에서 <label>과 연결된 <input type="radio">를 같은 행에 배치함
  • CSS는 컨테이너에 display: flex, flex-direction: row, align-items: center, gap: .5rem을 적용한 단순한 구조였음
  • 반복 클릭 중 라디오 버튼과 라벨 사이 공간을 누르면 컨트롤이 토글되지 않는 dead spot이 발견됨
  • 원인은 flexbox의 gap이었음
    • gap은 시각적 간격을 쉽게 만들지만
    • 라벨이나 입력 요소의 클릭 영역에는 포함되지 않아 상호작용의 빈 공간이 됨
  • 해결은 gap을 제거하고 label에 padding을 주는 방식이었음
    • 간격은 유지됨
    • 라벨의 클릭 가능한 영역이 넓어져 dead zone이 사라짐
  • 작은 결함 하나는 사소해 보여도, 이런 “작은 가시”가 많아지면 UI 경험은 고통스러워질 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 만들고 있는 제품을 직접 많이 쓰는 사용자이기도 한 개발자라면 이런 작은 문제를 찾는 데 매우 유리함
    사용자가 먼저 걸리기 전에 개발자가 직접 작은 거슬림을 발견하고, 바로 고칠 위치에도 있기 때문임
    그래서 강한 오너십을 가진 작은 팀이 효과적인 듯함. 제품에 주인의식이 있으면 사용자가 겪는 사소한 불편도 자기 일처럼 느껴지고, UX를 최대한 매끄럽게 만드는 게 자존심의 문제가 됨

    • 그래서 회사들이 가능할 때 제품을 도그푸딩하고 내부 베타를 돌리는 이유이기도 함
      기업용 제품처럼 내부에서 쓰기 어려운 경우가 아니라면, 직접적인 오너십은 약해도 제품 성공에 대한 이해관계는 생김

  • 가장 다듬어진 UI가 뭘지 궁금함
    FAANG 정도면 돈도 많으니 UI/UX가 꽤 괜찮을 것 같지만, Amazon.com이나 AWS, GCP, Azure를 써본 사람은 다르게 느낄 것임
    개인적으로는 mcmaster.com이 가장 잘 다듬어진 UI/UX라고 봄. 필요한 걸 몇 분 안에 찾을 수 있음
    반면 Home Depot이나 Lowe’s 같은 대형 매장 사이트에서는 나사나 목재 같은 걸 정확한 크기로 찾는 데 10~15분씩 걸리고, 모바일에서는 더 심함

    • RockAuto가 가장 좋아하는 웹사이트임
      믿기 어려울 정도로 단순하고 실용적인데도 꽤 강력함. 부품을 단계적으로 좁혀 찾거나 검색할 수 있고, 가격 비교가 자동으로 되며 가격/품질 범주도 유용하게 묶여 있음
      부품 번호를 찾으면 연식/제조사/모델 호환성, 간단한 설명, 사진, 장바구니의 다른 부품과 같은 창고에서 배송되는지도 볼 수 있음. 이 모든 게 한 페이지에서 마찰 없이, 어떤 플랫폼에서도 매우 빠르게 동작함
    • FastMail은 써본 웹 앱 중 감각이 가장 좋은 편임
      반응이 매우 빠르고 쓰는 동안 버그를 본 적이 없었음. 웹 앱이 어디까지 가능하다고 생각하는지 기준을 높여 줬음
    • Linear는 UI가 매우 잘 다듬어져 있음
      실제로 사용성 문제만 고치는 전용 기간도 있었음
      https://linear.app/changelog/2022-12-01-polishing-season-202...
      https://web.archive.org/web/20231003205004/https://linear.ap...
    • Facebook에는 몇 달째 망가진 기능을 여러 개 댈 수 있음
      특히 임시 프로필 사진이 제일 짜증남. 거의 1년 전부터 제대로 동작하지 않고, 원래 사진으로 돌아가지 않음
      거기서는 아무도 다듬고 있지 않은 듯함
    • 작은 디테일에 장인정신이 드러난다는 걸 모두가 볼 수 있는 시기임
      https://littlebigdetails.com이 딱 그런 곳임

  • 이 특정 문제의 기본 해법은 라벨 안에 입력 요소를 넣는 것임

    • Bootstrap은 라디오/체크박스에서 4.0의 구조를 5.0에서 다른 구조로 바꿨음 [1]
      이유가 궁금했는데, 라벨이나 입력 요소의 위치/패딩을 조정할 때 테마 적용이 더 단순해지기 때문일 것 같음
      [1] https://getbootstrap.com/docs/5.3/forms/checks-radios/
    • 중첩하더라도 일반적인 음성 명령 소프트웨어 접근성을 위해서는 for/id 속성이 여전히 필요함: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
    • 처음 떠오른 생각도 이거였음
      라디오나 체크박스는 박스와 패딩만이 아니라 전체 텍스트 라벨을 눌러도 토글되어야 함
    • 예전에는 왠지 이 방식이 금기라고 생각했는데, 아마 XHTML에서 라벨과 입력의 일대일 연결을 강제하던 것 때문이었을지도 모름
      Flexbox는 좀 과해 보임. 중첩하지 않은 문법이어도 인라인으로 배치될 테고, 같은 방식으로 패딩만 추가하면 된다고 봄
    • React 같은 프레임워크에서는 이 방식이 사이트에서 Google Translate 같은 걸 쓸 때 전파되는 오류를 만들 수 있음
      완화하려면 Foo를 별도 요소로 감싸야 함

  • 이런 건 Agile에서 너무 사라졌음
    엔지니어에게 제품을 다듬을 시간이 있어야 하는데 실제로는 없음. QA가 간격 문제로 티켓을 만들지 않으면 절대 고쳐지지 않음
    고객은 이런 걸 아마 알아차리겠지만, 보고해 주는 것도 기적이고, 그게 결국 티켓이 되는 것도 기적이며, 누군가 우선순위를 줘서 고치는 것도 또 기적임
    실제로 대부분의 회사 이슈 보드는 고객 입장에서 너무 불투명해서, 작은 문제나 버그를 발견하면 그게 버그임을 증명하고 추적기에 티켓을 넣기까지 50시간씩 왔다 갔다 해야 해서 짜증남

    • Agile이랑 무슨 상관인지 모르겠음
      폭포수 모델이 UI를 테스트하고 다듬을 시간을 명시적으로 줬다고 생각하는 건가?
      이건 보통 제품 관리자가 우선순위를 정하고, 유능한 UX 엔지니어나 디자이너와 함께 처리해야 하는 과정임. 원한다면 어떤 개발 방법론에도 그 우선순위를 넣을 수 있으니 여기서 Agile은 무관함
    • Discord에는 포럼처럼 동작하는 게시글 기능이 있는데, 거기서 글을 작성하면 HOME/END 키가 엉망이고 Shift로 텍스트 선택도 안 되며 Ctrl을 누른 단어 단위 이동도 안 됨
      지난 3년 동안 몇 번이나 보고했음. 작성 중 텍스트 편집이 극도로 어렵고 짜증나기 때문임
      웹 개발자로서 애초에 어떻게 이런 게 망가졌는지 궁금함. 기본으로 동작하는 걸 망가뜨리려면 어떤 수준의 무능이 필요한지 모르겠음. 30분 이상 걸릴 리 없는 수정이고 모두의 사용자 경험을 1000배 낫게 만들 텐데, 보고한 지 3년이 지나도 그대로임
      Teams에서도 전화번호 입력란에서 HOME/END 키를 쓸 수 없는 버그를 Microsoft Premiere Support를 통해 보고했는데, 답변은 “설계대로 동작함”이었음
      고객이 이런 버그를 더 이상 보고하지 않는 게 놀랍지 않음. 직원/개발자도 회사도 어차피 신경 쓰지 않기 때문임
    • 정말 맞는 말임
      제품의 리드 개발자인데 여기저기 작은 문제가 많이 있음. 어떤 것에 책임은 지고 있지만 고칠 권한은 없는 상태가 좋은 느낌일 리 없음
      비즈니스 관점에서는 매출이나 브랜드에 타격이 없는데 왜 시간과 돈을 들여 고치겠냐는 논리가 됨. 장기적으로는 브랜드에 영향을 주겠지만, 대부분은 5년 안에 역할이나 회사를 옮기니 신경 쓰지 않음
    • 버그를 많이 보고하는 편인데, 많은 고객지원 담당자가 자기 일을 엔지니어를 버그 보고로부터 보호하고 책임을 돌리는 것으로 보는 듯함
      답변이라도 받는다면 그나마 나은 경우임
    • “Agile”의 아이디어는 동작하지 않는 걸 알아차리고 개선하는 것임
      고객의 필요를 충족하지 못하는 프로세스가 분명히 있으니, 팀과 함께 고치면 됨
      Scrum 의식이 있다면 회고에서 꺼낼 수 있지만, 사실 언제든 가능함. 회고는 지난 몇 주를 일부러 돌아보는 자리일 뿐이고, 도중에 눈치챈 건 도중에 해결하려고 해야 함

  • 작은 UX 문제를 보고 고칠 수 있는 감각을 가진 사람이 정말 중요함
    UX 디자인에서는 이런 걸 사용자에게 생기는 종이 베임에 비유하곤 함. 치명적이지는 않지만 사용자 만족도를 깎아먹음
    글쓴이에게 덧붙이자면, 그 라디오 버튼은 선택 상태에 체크가 아니라 점을 쓰는 관례를 따르지 않음. 사용자는 첫눈에 여러 개 선택 가능하거나 아예 선택하지 않아도 되는 것으로 오해할 수 있음

    • GitHub와 Jira에서 겪은 건, 대화상자에서 텍스트를 드래그해 선택하다가 바깥에서 마우스를 떼면 팝업이 닫히는 문제였음
      바깥을 클릭하면 닫히게 한 기능의 부작용일 가능성이 큼
    • 동의함
      부정적인 쪽의 “Papercuts”가 있다면, 긍정적인 쪽에는 최근 HN에서도 다뤄진 Juice가 있음
      1. https://garden.bradwoods.io/notes/design/juice

  • 이 글은 내가 왜 UI 프로그래밍을 싫어하는지 잘 보여줌
    예측할 수 없고 사소하게 틀어질 수 있는 것들이 내 인내심을 넘어섬. 뭔가가 실패할 방식을 생각하고 테스트를 작성하는 건 어느 정도 즐기지만, 아무렇게나 클릭하면서 깨지는지 보는 건 산만하고 짜증남
    UI 구현이 본질적으로 이렇게 복잡한 건지, 아니면 아직 맞는 프로그래밍 모델을 못 찾은 건지 궁금함. 가끔은 처음부터 의도한 대로 보이고 동작하길 바라는 게 unreasonable한 걸까?

    • 그래서 디자인 시스템이 있는 것임
      UI를 다듬는 건 컴포넌트를 처음 만들 때만 하면 됨. 가끔 컴포넌트를 다른 방식으로 조합하거나 일회성 구현이 필요할 수는 있음
      솔직히 뭘 하는지 알고 있으면 그렇게 오래 걸리지 않음. 좋은 디자인 엔지니어는 이런 역할의 전문가임
    • 이건 UI 프로그래밍이 아니라 HTML과 CSS 위에서 UI를 설계하는 것임
      자유도가 너무 많고, 폼 같은 기본 요소는 기본값만으로도 잘 동작해야 함
    • 그렇게 복잡하지는 않음
      코드를 통해 UI를 잘 표현하는 방법은 이미 있음. 문제는 비즈니스 쪽의 제로섬 게임. 크로스 플랫폼 UI는 가장 보기 싫은 UI 스택인 HTML/CSS/JS로 하지 않으면 비용이 너무 비쌈
    • 과거에는 기본적으로 세부사항을 대신 신경 써 주던 꽤 괜찮은 플랫폼들이 있었음
      하지만 웹 플랫폼은 문서에는 그럭저럭 괜찮아도 앱에는 추상화 수준이 맞지 않음. 그래서 웹 UI가 매년 새롭고 새는 추상화로 재발명됨
    • 웹의 경우, 올바른 UI에 관심 있는 개발자를 도와줄 장치 없이 입도가 너무 낮은 결과임
      따라잡는 것만으로도 일이 너무 많음
      다른 영역에서도 비슷함. 요청을 보내거나 쿼리에 매개변수를 넣는 쉬운 방법이 없으면, 사람들이 조심하려 해도 자연스러운 압박 때문에 온갖 반쪽짜리 방식을 발명하게 됨
      웹 플랫폼은 그래픽 쪽으로는 최첨단이지만 UI로는 정말 형편없음. 그런데 아무도 그걸 인정하고 바꾸려 하지 않음. 사람들은 앞부분만 믿고, 브라우저의 레거시와 복잡성이 변화를 막음. 라이브러리로 만들면 “표준”이 아니라서 아무도 신경 쓰지 않음

  • 한편 어떤 UI는 라디오 버튼에 네모 박스를 쓰기도 함
    강조된 버튼이 있는데 Enter 키로 활성화되지 않기도 함
    또 서로 다른 기호(말줄임표, 햄버거, 케밥) 뒤에 메뉴가 세 개씩 숨어 있기도 함
    품질 편차가 큼. UI를 다듬는 사람들은 정말 고마운 존재임

    • 포커스된 버튼을 클릭처럼 실행하는 키는 보통 Enter가 아니라 Space라고 봄
    • 라디오 버튼도 이제 네모나 둥근 네모가 표준으로 가는 것 같음
      Apple마저 이러고 있음 :(

  • 왜 입력 요소를 라벨 안에 넣는 방식이 인기가 없는지 이해가 안 됨
    이렇게 하면 문제가 완전히 사라지고, for에 쓸 고유 id를 만들 필요도 없음

    • “인기 없다”기보다는 오히려 반대라고 봄
      다만 아직도 새로운 유효 표준 패턴을 해석하지 못하는 보조 기술이 몇 개 있다고 알려져 있어서, 청동기 시대 표준을 지키는 게 최선 관행이 됨 [1]

      Windows용 Dragon Naturally Speaking과 macOS/iOS용 Voice Control은 암시적 연결을 인식하지 못하므로, [명시적 for-id 참조 없이 label 안에 input을 중첩하는 방식]은 동작하지 않음
      Naturally Speaking은 “Microsoft”라는 회사에 인수되었다고 하고, Voice Control은 “Apple”이라는 회사와 관련이 있음
      [1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...

    • Rails 헬퍼로 체크박스를 만들면, 항상 값이 POST되도록 “off” 값을 가진 hidden 필드를 옆에 둠
      다른 프레임워크도 비슷할 것 같음. 그 두 입력 필드를 label 요소로 감싸면 더 이상 유효한 HTML이 아님
      라디오 버튼에는 문제가 아니지만, 몇몇은 이걸 겪고 나서 “확실히 하려고” 그렇게 하는 것 같음. JavaScript 줄 끝에 세미콜론을 붙이는 것과 비슷함. 거의 필요 없지만 정확히 언제 필요한지 모르니 어디에나 붙이는 식임
    • 최소 15년, 어쩌면 20년 전부터 이렇게 해 왔음
      체크박스/라디오 버튼의 일반적인 사용 사례에서는 문법도 훨씬 깔끔함
      입력 요소를 라벨로 감싸고, 텍스트에 스타일을 주고 싶으면 텍스트를 span에 넣으면 됨. label을 display:flex로 만들고 텍스트 위치도 그렇게 처리할 수 있음
    • 시맨틱 웹이라는 교리 때문임

  • 버그 배시에서는 이 방식을 쓰는데, 테스트 케이스 조합을 다차원 데카르트 곱 행렬로 만든 사람보다 훨씬 더 많은 티켓이 나옴
    시작점으로 그런 테스트 케이스를 아는 건 좋지만, 작은 문제를 찾으려면 무작위 테스트가 계획된 테스트를 빠르게 앞지름
    계획된 테스트는 대개 정상 경로나 예상된 오류에 머무름. 이런 다듬기 방식은 모서리 버그를 훨씬 빨리 찾아냄

    • 가끔, 특히 전체 기능을 작업하기에는 너무 피곤할 때 게임에서 여기저기 무작위로 클릭하고 평소 안 해 보던 걸 시도함
      항상 문제나 작은 개선점을 발견하게 됨. 계획된 테스트로는 실제로 많이 나오지 않았을 것들임

  • 개인 웹사이트(https://dustinbrett.com)를 거의 4년째 다듬고 있는데, 끝없이 계속될 수 있을 것 같은 느낌임
    다행히 작업하는 걸 즐기고 있음

    • 솔직히 말해 보자면, 여기에 쓴 시간 중 얼마나 많은 시간이 9시~5시 근무 중이었고 상사 돈으로 처리됐는지 궁금함
      전부였길 바람 :-)
    • 이런 건 정말 좋음
      “웹페이지 위의 데스크톱 OS”를 보면 대부분 반쯤 만든 느낌이고 솔직히 너무 흔해졌다고 느끼는데, 이건 반대로 아주 탄탄하고 잘 다듬어져 있음
    • 둘러보는 재미가 큼
      정말 잘 만들었고 영감을 줌. 모든 걸 어떻게 구현했을지 생각하는 것도 꽤 즐거움
    • 매우 부드럽고, 내가 몰랐던 욕구를 긁어 줌
      휴대폰에서 창 기반 OS를 쓰고 싶다는 욕구였음
    • 정말 멋져 보임
      빠진 걸 하나 찾자면 explorer에서 mouse4/mouse5를 쓸 수 없다는 점임. “다듬기”는 정말 영원히 계속될 수 있음
답변달기