Final Project에서 맡은 페이지는 플랫폼 관리 페이지로, 요식업 사장님이 자주 드나드는 사이트를 모아두는 페이지입니다.
각 사이트는 카드 형식으로 표현되며, 세 가지 입력 항목이 있습니다.
첫 번째로는 이미지를 등록할 수 있는 file input이 있고,
두 번째로는 자주 들어가는 사이트의 링크를 입력하는 text input이 있습니다.
마지막으로 세 번째로는 링크의 제목을 넣는 input text도 있습니다.
프로젝트를 시작하기 전, 몇 명의 팀원은 URL 유효성 검사를 추가하는 것이 좋다고 제안했습니다. 그러나 URL 유효성 검사를 구현하면서 "현재 만들고 있는 플랫폼 카드에 URL 유효성 검사가 정말 필요한가"라는 의문이 들었습니다.
프로젝트 진행 전에는 비동기 통신 실패에 대한 에러 처리에 대한 다양한 방법을 검토했습니다. 이 과정에서 현업에서는 에러의 크기에 따라 처리 방식을 나누는 방법을 채택한다고 합니다. 큰 규모의 에러는 반드시 개발자가 처리해야 하지만, 사용자 경험에 직접적인 영향을 미치지 않는 작은 규모의 에러는 그냥 놔둬도 되는 규모의 에러도 있다고 합니다.
한편의 예로 위 플랫폼 카드 형식의 이미지 미리보기와 관련하여 open-graph-scraper 라이브러리를 사용하고 있는데, 해당 URL에서 ogImage가 없을 경우 에러를 별도로 처리할 필요는 없다고 판단했습니다. Open Graph의 og:Image를 불러와서 status 상태가 200이면 성공한 상태이지만 그 이외의 500, 494 status 상태는 개발자 입장과 통신 측면에서 에러이지만 사용자에게 UX 적으로 선택적 서비스를 선사하기 위한 기능이기에 굳이 og:Image를 추출하지 못했다고 하여 에러로 치부하고 개발자가 이미지가 없습니다 라는 내용을 사용자에게 보여줄 이유가 없다 판단 됩니다. 사용자에게는 이미지가 있으면 미리보기로 제공되고, 없으면 사용자가 직접 이미지를 등록하면 되기 때문입니다.
이를 고려하여 URL 유효성 검사의 필요성을 다시 고민했습니다. URL 형식이 잘못되었다는 에러는 사용자 경험에 큰 영향을 미치지 않을 것으로 판단했습니다. 각 사용자가 URL에 대한 개념을 다르게 가질 수 있기 때문입니다. 예를 들어, 누군가는 "https://www.naver.com"를 입력하고, 다른 누군가는 "www.naver.com"을 입력하며, 더 다른 사용자는 "naver.com"만으로도 자신이 원하는 웹페이지로 이동한다고 생각할 수 있습니다.
이러한 다양한 URL 입력 방식을 고려할 때, URL 형식이 정확하지 않다는 에러를 강제로 피드백하는 것은 사용자들에게 혼란을 줄 수 있다 판단했고, 그로 인해 사용자 경험과 각자의 편의성을 존중하는 관점에서 URL 유효성 검사를 넣지 않는 결정을 내렸고
URL 유효성 검사의 경우, 사용자에게 불편함을 초래할 수 있기 때문에 사용자가 직접 제어권을 가지는 방식이 더 적절하다고 결론내렸습니다.
사용자는 플랫폼 카드를 등록하거나 편집할 때 직접 URL을 확인하고 수정할 수 있어, 자유롭게 자신만의 방식으로 입력할 수 있도록 하였습니다.
최종적으로, URL이 형식에 맞지 않으면 경고창을 띄우는 대신 사용자가 플랫폼 카드를 등록하거나 편집할 때 직접 URL을 확인하고 수정할 수 있는 로직을 추가했습니다. 이렇게 함으로써 사용자는 자신이 원하는 페이지로 이동하기 위한 URL 제어를 선택할 수 있게 하였고
사용자 경험 측면에서 URL 유효성 검사를 통한 불편함이 예상되기 때문에 개발자의 개입보다는 사용자가 직접 제어하는 것이 더 적절하다 생각합니다.
에러가 발생할 경우, 사용자에게 알맞게 안내하는 것이 정답이 아니라면 그 에러는 무시해도 좋다는 점을 고려하여, URL 유효성 검사를 넣지 않고 https://가 있는지 여부를 확인하여 로직을 구성했습니다. 또한, 플랫폼 카드를 편집할 때 사용자가 직접 작성한 URL을 확인할 수 있는 UI를 추가하여 사용자가 스스로 플랫폼을 통제할 수 있도록 로직을 설계했습니다.
이러한 고려를 통해 사용자에게 보다 자유로운 경험을 제공할 수 있을 것으로 생각합니다.
귯