UI/UX의 복잡성이라고 표현할 수도 있지만,
자유든 상용이든 요즘 만들어지는 소프트웨어들은, 통과하는 딱 1가지의 경우만 통과하게 만들고 그 외의 경험들은 어떻게 되든 그다지 신경쓰지 않는 게 문제라고 생각합니다.
이를테면 toml이나 yaml configuration을 편집할때도 반드시 되어야 할 것 같은데 안될때가 있습니다. 이게 인코딩 문제인지 indentation문제인지, 아니면 특정 flag가 있을 때는 쓰지 못하는 기능인지 아닌지 이런 내용이 보통 제대로 문서화되어있지 않습니다. 사용자는 오만가지 케이스를 일일이 시도해보다가 어렵게 정답을 찾곤 합니다.
UI에서는 더 심각합니다. 흔히 password reset할때 경험하는 일이 밈처럼 퍼져 있듯이, 화면에 100가지의 필드가 있으면 상호간의 연관성이 어떤지, 어떻게 바꾸는 게 최적인지 "해 보지 않고서는 알 수 없습니다".
이건 UI/UX의 문제이기도 하지만 숨겨진 "전문성"의 문제이기도 합니다. 일종의 단계형 러닝커브가 준비되어 있지 않은 상태에서 전문성이 있는 사람이면 바로 정답을 기입할 수 있는 문제가, 초심자에게는 시험이나 관문처럼 수많은 거절을 경험하게 하는 역할을 하는 것이지요.
UI/UX의 복잡성이라고 표현할 수도 있지만,
자유든 상용이든 요즘 만들어지는 소프트웨어들은, 통과하는 딱 1가지의 경우만 통과하게 만들고 그 외의 경험들은 어떻게 되든 그다지 신경쓰지 않는 게 문제라고 생각합니다.
이를테면 toml이나 yaml configuration을 편집할때도 반드시 되어야 할 것 같은데 안될때가 있습니다. 이게 인코딩 문제인지 indentation문제인지, 아니면 특정 flag가 있을 때는 쓰지 못하는 기능인지 아닌지 이런 내용이 보통 제대로 문서화되어있지 않습니다. 사용자는 오만가지 케이스를 일일이 시도해보다가 어렵게 정답을 찾곤 합니다.
UI에서는 더 심각합니다. 흔히 password reset할때 경험하는 일이 밈처럼 퍼져 있듯이, 화면에 100가지의 필드가 있으면 상호간의 연관성이 어떤지, 어떻게 바꾸는 게 최적인지 "해 보지 않고서는 알 수 없습니다".
이건 UI/UX의 문제이기도 하지만 숨겨진 "전문성"의 문제이기도 합니다. 일종의 단계형 러닝커브가 준비되어 있지 않은 상태에서 전문성이 있는 사람이면 바로 정답을 기입할 수 있는 문제가, 초심자에게는 시험이나 관문처럼 수많은 거절을 경험하게 하는 역할을 하는 것이지요.