brunch

You can make anything
by writing

C.S.Lewis

by UX 컨설턴트 전민수 May 11. 2017

모바일 앱 검색 서비스 UX 원칙

Today

Today UX 아티클


raywenderlich.com에 올라온 모바일 앱 검색 서비스 베스트 사례 20 번역한 글입니다. 


사람들의 일상생활에 도움이 되는 멋진 앱을 만들었다고 해봅시다. 훌륭합니다! 그 앱은 유저가 길을 찾거나 옷을 구매하거나, 재미있는 GIF를 찾거나 뉴스를 읽는 데 도움이 될 것입니다. 물론 유저에게 훌륭한 콘텐츠를 제공해주는 서비스를 만들었다면 말이죠. 


유저가 앱을 다운로드한 후에 해야 할 유일한 행동은 콘텐츠를 찾는 것입니다. 


이론적으로는 쉽게 들릴지 모르지만, 실질적으로 항상 매끄럽게 되는 일은 아닙니다. 앱을 이용하면서 찾고자 하는 것을 찾지 못해 고생하다가 결국 절망하며 구글의 도움을 받았던 적이 얼마나 있으신가요? 


앱을 꼭 그렇게 만들 필요는 없습니다. 이번 글에서는 모바일 앱 검색 디자인의 모범 사례 20가지를 공유하여 그 해결책을 보여드리고자 합니다.


성공적인 모바일 앱 검색 기능은 훌륭한 대화와 같다 


앱의 검색 기능은 여러분이 제공하는 모든 콘텐츠에 유저가 접근할 수 있도록 도와주기 때문에 매우 훌륭한 기능입니다. 하지만, 성공적으로 검색하려면, 유저는 다음 세 가지를 알기 위해 여러분이 만든 앱과 제품에 대한 기본적인 이해를 하고 있어야 합니다.

어떻게 검색할 것인지
무엇을 검색할 것인지
검색어를 뭐라고 입력해야 할 것인지


이러한 정보 격차를 해소하기 위해서는, 성공적인 검색 인터랙션은 여러분과 유저가 서로 나누는 훌륭한 대화가 되어 그들이 필요로 하는 것을 찾는 데궁극적인 도움이 되어야 합니다.


검색은 세 가지 주요 구성요소로 나누어 생각해볼 수 있습니다.

1.  검색어를 입력함
2.  ‘검색 결과가 없음’이란 결과가 보임 (매치되는 결과가 없는 경우)
3.  검색 결과가 보임 (적어도 하나의 매치되는 결과가 있는 경우)


각각에 대해 자세히 살펴보도록 합니다. 


검색어 입력하기


유저는 결과를 보기 전에 검색바(searchbar) 같은 것에 검색어를 입력해야 합니다. 그럼 데이터베이스에서 검색어와 매치되는 데이터를 찾게 되고 적절한 결과가 나오게 됩니다.

하지만 불행하게도, 여러분이 만든 앱에 강력한 검색 엔진이 없다면, 바람직하지 않거나 이해하기 어려운 검색 결과가 나오게 될 것입니다. 

그래도 두려워하지 마세요! 1번부터 8번까지의 모범사례를 보면 유저가 원하는 목표로 방향을 잡는 데 도움을 줄 수 있을 것입니다.


1. 검색을 쉽게 발견할 수 있게 만든다


유저의 인게이지먼트를 끌어올리는 데 검색에 크게 의존하는 앱이라면, 검색 인터랙션을 쉽게 찾을 수 있게 해야 합니다. 스크린 상단에 검색바가 계속 보이게 만들 수도 있고 탭바나 내비게이션 바 같은 눈에 잘 띄는 위치에 돋보기 아이콘을 배치할 수도 있습니다. 


Medium은 검색 아이콘을 네비게이션 바에서 보여줍니다.


Tumblr는 탭 바에서 검색 아이콘을 좀 더 눈에 띄게 배치합니다.


2. 플레이스홀더(placeholder)를 힌트로 활용한다


검색바에 “검색” 같은 포괄적인 플레이스홀더를 사용하지 마시고, 유저가 찾아야 하는 유형의 정보가 무엇인지 알려줄 수 있도록 좀 더 서술적인 문구를 써보세요. 만일 검색 기능에 제약이 있을 경우, 여기서 설명을 해서 앱에서 어떤 유형의 검색이 가능한지 유저가 알 수 있게 해주세요.


Bad Case: Messenger


Messenger는 검색 박스에 단순히 “검색”이라고만 써있습니다. 마치 무엇이든 검색해도 될 것처럼 보입니다.


Good Case: Robinhood


Robinhood는 무엇을 검색할지, 어떤 검색 결과를 기대할 수 있는지 알려주는 일을 훌륭하게 해냈습니다. 회사나 금융 제품을 검색할 수 있다는거죠.

보통, 특정 회사의 주식을 찾으려면 ticker symbol로 찾아야 합니다. 하지만 Robinhood에서는 주식 거래가 쉽지 않은 테마임에도 불구하고, 초보자들도 쉽게 접근할 수 있도록 회사명으로도 검색할 수 있게 만들었습니다.


3. 추천 검색어를 제공한다


여러분이 저지를 수 있는 최악의 실수 중 하나는 유저가 검색바를 눌렀을 때 검색바 아래로 빈 화면을 보여주는 것입니다. 모바일 스크린에는 공간이 많지 않으니 빈 공간도 낭비하면 안 됩니다. 

이런 빈 공간은 유저와 소통함에 있어서 유저를 가이드해줄 수 있는 좋은 기회입니다. 유저에게 “인기 검색어”, “즐겨찾기”, “가장 유사한 검색어” 등과 같은 추천 검색어나 큐레이트 된 콘텐츠를 제공하는 공간으로 활용해보세요.


Bad Case: Skillshare


Skillshare의 검색 기능은 검색 방법에 대한 제안을 전혀 제공하지 않고 있어서 아쉬움이 많습니다. 문자그대로 유저를 어둠 속에 던져 둔 것이죠.


Good Case: Pinterest 


 Pinterest는 인기 검색어 리스트를 보여줌으로 유저가 “잘 알고 있는”상태를 유지할 수 있게 해줍니다.

이런 패턴의 장점은 유저가 검색어를 입력할 필요도 없이 검색 행동을 할 수가 있다는 점입니다. 여러분이 관련된 결과를 보여준다고 보장할 수 있는 미리 정해진 콘텐츠에서 선택하면 되는 거죠. 


4. 자동 완성 기능을 제공한다


가장 인기 있고, 유용한 디자인 패턴 중 하나는 자동 완성 혹은 “검색 결과 내 검색”입니다. 유저가 검색어를 입력하면, 앱이 몇 가지 관련된 검색어를 제안해 주면 유저가 쉽게 선택할 수 있습니다. 이는 특히 모바일 유저에게 가장 유용한 기능 중 하나입니다. 타이핑할 시간을 줄여주기 때문이죠. 또한 앱의 제작자로서 여러분이 유저에게 가장 맞다고 생각하는 방향으로 유저를 정중하게 안내할 수 있게 해줍니다. 


Bad Case: iTrans NYC


iTrans NYC는 유저가 거의 전체 주소를 입력할 때까지 무엇을 입력하려는 것인지알아내지 못합니다.


Good Case: Cookpad


Cookpad는 유저의 검색어를 살펴보고 유저가 누를 만한 복잡하고 구체적인 검색어를 보여줍니다.


Good Case: Lyft


Lyft같이 위치 정보가 필요한 앱은 자동완성 기능이 없으면 거의 무용지물이나 다름 없습니다.



5. 카테고리 내 검색 기능을 제공한다


유저가 찾아 들어갈 카테고리 안에서 검색을 할 수 있게 해주는 것은 특별한 검색 기능입니다. 많은 앱이나 비즈니스에서 이런 모델을 제공하진 않지만, 대부분의 유저는 기대하는 기능이죠. 이러한 유형의 검색은 오류를 방지할 수 있게 해주기도 합니다. 유저가 결과를 반드시 찾을 수 있는 카테고리로 들어갈 수 있도록 가이드 해 주기 때문입니다. 


Good Case: Spring


유저가 검색어를 입력하면, Spring은 검색어를 검색할 수 있는 카테고리와 카테고리 별 결과 수를 보여줍니다.


6. 검색 기록을 저장한다


유저는 자신이 이전에 했던 것을 앱이 기억하고 있으면 좋아합니다. 특히 브라우징과 관련해선 더 그렇습니다. 여러분이 완벽한 버터 나이프를 찾고 있었는데 전화나 알림이 떠버리는 바람에 처음부터 다시 검색해야 한다고 상상해보면 쉽게 알 수 있습니다.


검색 플로우에 이러한 섹션을 넣어주는 것은 여러분의 제품에 대한 유저의 신뢰를 높여주며 더 탐색하고자 하는 마음을 가지게 해줍니다. 검색 기록을 저장했다가 보여주는 방법엔 두 가지가 있습니다. 유저가 입력한 검색어를 자동으로 저장했다가 분류해주거나, 유저가 주도적으로 검색한 것을 저장하게 해줄 수도 있습니다. 


So-So Case: Evernote


Evernote는 유저의 행동을 기억하는 데 두 가지 옵션을 모두 제공해줍니다. 최근 검색 기록을 자동으로 저장해두기도 하며 유저가 직접 나중을 위해 검색 내용을 저장할 수 있게도 해줍니다. 유저는 검색을 직접 저장할 수 있는 기능을 좋아하긴 하겠지만, 여러 단계를 거쳐야 해서 짜증을 유발합니다.

Evernote


So-So Case: Amazon


Amazon은 유저의 검색을 저장해두긴 하지만, 기록을 하나식 지우는 것은 복잡합니다.


Good Case: Medium


Medium은 깔끔하게 유저의 검색 결과를 저장해 두었다가 보여주며, 검색 히스토리를 간단하게 지울 수도 있어 어수선하지 않습니다.


7. 영역별 검색 기능을 제공한다


전체 콘텐츠가 여러 카테고리로 분류될 수 있다면, 영역별 검색을 고려해볼 수도 있습니다. 영역별 검색은 유저가 자신이 검색 결과를 보고 있는 “공간”이 어디인지 쉽게 알 수 있게 해줍니다. 영역이 명확하게 보이고 쉽게 전환할 수 있다면 말이죠.


Good Case: ProductHunt


유저가 검색어를 입력하면, ProductHunt는 유저가 검색할 수 있는 네 가지 분명하고 대단히 중요한 콘텐츠 카테고리를 제공합니다.


8. 검색을 제약한다


앱에서 특정 유형의 콘텐츠를 제공하고 있다면, 유저가 원하는 것을 찾을 수 있도록 도와주는 가장 좋은 방법은 몇 가지 기준으로 검색할 수 있도록 제약을 두는 것입니다. 그렇게 하면 앱은 유저가 어떤 정보를 입력해야 검색해 줄 수 있는지 명확하게 보여줄 수 있고, 유저는 그런 제약 안에서 원하는 것을 최대한 구체적으로 입력할 수 있습니다.


Good Case:Airbnb


Airbnb는 검색 영역 첫 화면부터 지역, 날짜, 게스트 수 등 중요한 것이 무엇인지 유저에게 알려줌으로 검색을 잘 제약했습니다. 
주석: 일부 사례를 보고 아셨겠지만, 위에서 소개한 방법들 중에 하나만 골라서 사용해야 하는 것이 아니고, 병행해서 사용해도 됩니다. 여러분이 가진 제품의 유형에 따라 선택하시면 됩니다. 


결과 없음 보여주기


유저와 앱 모두 검색어 입력이라는 힘든 일을 해냈으니, 이제 결과를 보여줄 차례입니다!

혹은 못 보여줄 수도 있습니다…



앱에 새로운 기능을 디자인해서 넣을 때는 언제나 “유저가 오류를 인지하고, 이해하고, 극복할 수 있도록 도와주어야 한다”는 사용성 원칙을 따라야 합니다. 기본적으로 최악의 케이스 시나리오를 먼저 생각해보고, 유저가 문제를 해결할 수 있는 스텝을 밟아보세요.


‘검색 결과 없음’ 페이지의 가장 좋은 점은 몇 가지 메커니즘을 통해 유저와 신뢰를 쌓을 수 있는 훌륭한 기회를 제공해준다는 점입니다.

 

모범사례 9번부터 13번까지 보면 최선의 검색 결과 없음 페이지를 만드는 방법을 알 수 있을 겁니다.


9. 문제를 전달한다


무언가 잘못되었음을 솔직하게 보여주고, 가능하다면 이슈가 무엇인지 유저에게 알려주세요. 


Good Case:Etsy



10. 오타는 고쳐준다


오타는 검색 결과가 없다는 스크린이 보이는 주된 이유 중 하나이기 때문에 이를 감지해서 고쳐주는 것은 좋은 아이디어입니다.


Good Case:Google



11. 덜 구체적으로 검색해준다


검색 결과가 없다는 스크린이 보이는 또 다른 주된 원인은 유저가 지나치게 구체적으로 검색한 경우입니다. 이를 해결하기 위해서, 유저가 입력한 검색어에서 일부를 제거해주면 매치가 되는 결과를 보여줄 수 있습니다. 만일 유저가 특정 카테고리 내에서 검색을 하고 있었다면 카테고리 전체를 볼 수 있게 해줄 수도 있습니다.


Good Case:Amazon




12. 대체 콘텐츠를 보여준다


그래도 보여줄 결과가 없다면, 대체 결과로 큐레이트 된 콘텐츠나 인기 검색어를 제공할 수도 있습니다.


13. 필요하다면 로그인 옵션을 제공한다


로그인이 필요한 카테고리 내에서 검색을 했다면, 로그인하거나 회원 가입할 수 있는 옵션을 보여줍니다.


Good Case: Rent the Runway

Rent the Runway는 익명의 유저가 MyHearts 카테고리를 이용할 수 있게 해준 후에, 하트를 누른 아이템을 보려고 하거나 구매하려고 하면 가입하는 화면으로 넘어갑니다


결과 보여주기


유저가 길을 잘 따라갔다면, 찾고 있던 결과를 얻었을 것입니다. 하지만, 그냥 모든 검색 결과를 페이지에 던져 놓고 유저가 알아서 이해하길 바라면 안 된다는 점을 아셔야 합니다. 


모범사례 14번부터 20번까지를 보면 유저가 검색 결과를 보면서 방향감과 공간감을 가질 수 있도록 만드는 데 도움이 될 것입니다.


14. 디폴트 정렬 기준을 고민해본다


검색 결과를 보여줄 때는, 결과를 보여주는 디폴트 된 논리적 순서를 쉽게 보고 인지할 수 있게 해야 합니다. 알파벳 순이나 가격순, 날짜 순, 거리 순 등의 방법이 있습니다. 고객이나 제품과 가장 관련 있다고 생각되는 방법으로 결과를 정렬해서 보여주세요. 


Bad Case: Google


Google이 검색에 있어서는 일반적으로 훌륭하긴 하지만, Google Maps에서 사용하는 디폴트 정렬은 약간 혼란스럽습니다. 유저는 거리에 따라 결과가 정렬될 것이라고 기대하지만, 실제 검색해보면 그렇지 않습니다.


15. 결과를 카테고리 화한다


앱에 검색 기능이 필요하다는 말은 곧 특정 카테고리로 분류될 수 있는 콘텐츠를 가지고 있다는 뜻입니다. 어패럴의 경우엔, 옷, 액세서리, 신발 등으로 분류될 수 있겠죠. 이는 검색 결과 앞에 헤더(header)를 넣어서 간단하게 해결할 수 있습니다.


Bad Case: Netflix



Good Case: Spotify



16. 도움이 되는 뷰 옵션을 제공한다


검색 결과는 다양한 모드로 보일 수 있습니다. 지도 위에 보일 수도 있고 리스트, 캐러셀, 썸네일 등으로 보일 수도 있습니다. 콘텐츠에 가장 적합한 방법으로 결과를 보여주세요. 검색 결과를 다양한 방법으로 보여줄 수 있다는 것이 꼭 그렇게 보여줘야 한다는 뜻은 아닙니다. 특히 뷰 방법을 변경하는 데 여러 단계가 필요한 경우엔 더 그렇습니다. 


Bad Case: HomeDepot


HomeDepot는 세 가지 뷰 옵션을 가지고 있지만, 각 옵션이 제공해주는 부가가치는 별로 없습니다. 또한 유저가 뷰방법을 변경하려면 탭을 두 번 해야 해서 거추장스럽기도 합니다


Good Case: Airbnb


Airbnb는 유저가쉽게 살펴볼 수 있는 ‘지도 뷰’에서 ‘빠른 예약 뷰’로 쉽게 전환할 수 있게 해줍니다. 두 옵션 모두 유저에게 서로 다르면서도 적절한 가치와 정보를 제공합니다


17. 페이지 네이션보다는 무한 스크롤링이 낫다


검색 결과를 보여줄 때 페이지를 나눠서 보여주는 앱이 많지는 않습니다. 그럼에도 불구하고 무한 스크롤링과 지연 로딩 패턴이 페이지를 나눠서 보여주는 결과보다 더 낫다는 것을 다시 한 번 언급할 가치는 충분합니다. ‘더 보기’ 버튼도 페이지 네이션보다 더 낫습니다. 


18. 검색 진행상황을 보여준다 


검색이 즉시 뜨지 않으면 유저는 무언가 잘못되었다고 생각하게 될 것입니다. 유저가 그냥 앉아서 멍하니 있게 만들지 마세요! 그 대신 진행 바나 HUD를 보여주어 작업이 진행 중임을 알 수 있게 해주세요. 


19. 결과의 수를 보여준다


검색 결과를 카테고리 화해서 보여주기로 했다면, 각 카테고리마나 얼마나 많은 제품이 있는지 보여주는 것은 좋은 아이디어입니다. 


Good Case: Booking.com


Booking.com에서는 유저가 검색을 하면 바로 결과를 논리적으로 카테고리화 하고각 카테고리마다 몇 개의 결과가 들어가는지 보여줍니다.


20. 키워드는 강조한다


때로는 결과를 보고 검색 결과가 내가 입력한 검색어와 어떤 관계가 있는지 한눈에 알아보기 어려울 때도 있습니다. 검색 키워드는 강조를 해줘서 유저가 쉽게 알아볼 수 있도록 도와줄 수 있습니다.


Good Case: Reminders


Reminders


여기서부턴 어디로 가야 할까요?


여러분이 만든 앱을 면밀히 살펴보시고, 위에서 말씀드린 사례 중 여러분의 유저가 보다 나은 검색 경험을 하는 데 도움이 될 수 있는 것은 없는지 생각해보세요. 위에서 말씀드린 좋지 않은 요소들이 여러분의 앱에도 들어있진 않나요? 어떻게 바꾸시겠습니까?


앱의 검색 기능은 콘텐츠 탐색의 일부분일 뿐입니다. 또 다른 부분은 ‘필터링’이라는 건데, 이에 대해선 다음 글에서 살펴보도록 하겠습니다. 





라이브 클래스 PM VOD 패키지(리서치/분석/전략/설계)


178여개 UX 강좌(총 300시간) PM VOD 패키지 98% 할인 이벤트!!!! 매일 하루에 딱 한명만!!!! 선착순 1명!!!! 

https://ebprux.liveklass.com/



매거진의 이전글 링크의 어포던스

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari