Як спроєктувати інтернет-портал зі зручною навігацією
На порталі нерухомості можуть бути десятки тисяч оголошень, але яка від них користь, якщо знайти потрібну квартиру майже неможливо? Людина шукає двокімнатне житло в Києві, поруч із метро та в межах свого бюджету. Натомість отримує сотні пропозицій, серед яких доводиться довго шукати відповідні. Для великих порталів це головний виклик: недостатньо зібрати багато інформації, потрібно ще допомогти людям у ній розібратися.

Чому пошук не вирішує всіх проблем
Здавалося б, достатньо додати пошуковий рядок і кілька фільтрів. Але пошук працюватиме добре лише тоді, коли самі оголошення правильно організовані.
Якщо в одному описі зазначено станцію метро, в іншому — лише район, а в третьому написано «зручне розташування», знайти всі квартири біля потрібної станції буде складно. Навіть хороший пошуковий алгоритм не замінить відсутніх даних.
Не менш важливо, як названі розділи та фільтри.
Nielsen Norman Group пояснює це через поняття information scent — інформаційні підказки, за якими людина оцінює, чи приведе посилання до потрібного результату.
Наприклад, «Оренда квартир» одразу повідомляє, що міститься в розділі. А назва «Наші пропозиції» змушує здогадуватися.
Тому контент для сайту — це не лише тексти й фотографії. Це також назви категорій, характеристики об'єктів і зв'язки між сторінками.
Перевірити, чи працює така структура, можна за допомогою юзабіліті-аудиту. Наприклад, попросити кількох людей знайти квартиру з конкретними характеристиками й подивитися, де виникають труднощі. Іноді для покращення пошуку не потрібен новий алгоритм — достатньо перейменувати незрозумілий фільтр.
Як QuintoAndar покращила портал із 40 тисячами сторінок
Бразильська компанія QuintoAndar зіткнулася з іншою проблемою. Її портал нерухомості містив великий інформаційний розділ із понад 40 тисячами сторінок про житлові комплекси, райони та доступні квартири.
Користувачі могли знайти потрібну інформацію, але сайт працював повільно: сторінки довго завантажувалися, елементи зміщувалися, а взаємодія із сайтом затримувалася.
У кейсі на web.dev компанія розповіла, як вирішувала ці проблеми. Розробники перейшли на Next.js, оптимізували зображення, скоротили обсяг JavaScript і переглянули функції, які навантажували сторінки.
Одна з деталей особливо цікава. Команда з'ясувала, що кнопкою додавання об'єкта до вподобаних користувалися менш ніж 0,5% відвідувачів відповідної сторінки. Водночас для її роботи потрібно було завантажувати додатковий код. Функцію вирішили прибрати.
Після комплексного оновлення компанія повідомила про такі результати:
- на 87% більше переглянутих сторінок за сеанс;
- на 46% нижчий показник відмов;
- на 5% кращу конверсію на етапі перевірки.
Це результати всього проєкту, а не доказ того, що саме Next.js або видалення однієї кнопки забезпечили приріст.
Найцікавіше тут те, що компанія з величезним обсягом інформації покращувала портал не додаванням нових можливостей, а переглядом уже наявних.
Чому великі портали складніше підтримувати
Коли на сайті сто сторінок, помилку в одному шаблоні можна швидко помітити. Коли сторінок десятки тисяч, той самий недолік повторюється по всьому порталу.
Наприклад, якщо шаблон неправильно обробляє фотографії, проблема виникатиме в кожному новому оголошенні. А зміна логіки фільтрів може вплинути одразу на сотні категорій.
Тому технічна підтримка сайтів такого масштабу — це не лише виправлення окремих помилок. Потрібно постійно стежити за швидкістю, коректністю пошуку та роботою спільних компонентів.
Історія QuintoAndar добре показує, що зростання порталу не обов'язково повинно супроводжуватися збільшенням його складності для користувача.



