Three products. One experience. Архітектура проєкту складалась з трьох основних напрямків. Той самий принцип, що ми пізніше описали ширше у Більшості компаній не потрібен новий сайт. Їм потрібна нова структура.
Gastro Market. Невеликий за масштабом бізнесу, але повноцінний e-commerce з каталогом приблизно на 2 000–3 000 товарів. Категорії, пошук, фільтрація, картки товарів, кошик, замовлення і всі основні механіки інтернет-магазину. Це був самостійний shopping experience, але не окремий сайт.
Delivery. Другий напрямок, власна доставка. Тут мова йшла вже не просто про сторінку з меню і телефоном. Ми проєктували повноцінний delivery service: сайт плюс мобільні застосунки для iOS і Android. Користувач мав мати можливість обрати страви, оформити замовлення і взаємодіяти з сервісом незалежно від того, перебував він зараз у ресторані чи вдома.
Restaurant. Третя частина, сам ресторан. Тут завдання було зовсім іншим. Якщо гастромаркет мав продавати, а delivery забезпечувати зручність замовлення, ресторанна частина мала передавати саме відчуття LavShash.
Місце, куди хочеться приїхати. Поїсти. Залишитись. Повернутись.
Built around a real product. У цьому проєкті була ще одна перевага.
За інтерфейсом реально стояв продукт, що люди любили.
LavShash був відомий своєю кухнею, і деякі страви ми самі досі згадуємо без жодної потреби додавати до цього маркетингові епітети.
Суп з маленькими пельменями. Шашлик.
Саме такі речі і роблять digital-проєкт осмисленим.
Можна спроєктувати ідеальний checkout. Можна побудувати складний каталог. Можна зробити красивий застосунок.
Але зрештою людина повертається не до інтерфейсу.
Вона повертається за тим, що їй реально подобається.
From Figma to code. Проєкт пройшов достатньо далеко.
Після проєктування ми перейшли до програмування, і більша частина архітектури вже була підготовлена до реалізації.
Потім почалась повномасштабна війна, і робота над проєктом була зупинена.
На цьому етапі LavShash лишився між дизайном і завершеним продуктом.
Але сама концепція збереглась.
І сьогодні проєкт все ще існує як робота, що ми хотіли б колись довести до кінця.
Не тому, що нам потрібно закрити старий пункт у портфоліо. А тому, що сама ідея була правильною.
One business, not three websites. LavShash став для нас хорошим прикладом того, як ми взагалі підходимо до digital-продуктів.
Коли у бізнесу кілька напрямків, найпростіший шлях, зробити для кожного окремий сайт.
Ми надаємо перевагу спочатку подивитись на бізнес цілком. Зрозуміти, де реально різні продукти, а де вони є частинами однієї системи. І лише після цього проєктувати інтерфейси.
Та сама дисципліна стояла за тим, як це партнерство підійшло до зовсім іншого бізнесу у Building the Next Century: PERETZ починає цифрову трансформацію Schoeffel.
У LavShash ми об'єднали restaurant, e-commerce і delivery в одну цифрову екосистему, з окремими сценаріями, власними інтерфейсами і мобільними застосунками, але зі спільною архітектурою і єдиним користувацьким досвідом.
Саме це, а не кількість сторінок чи технологій, було головним продуктовим рішенням проєкту.
The homepage wasn't the destination. Одним з принципових рішень була сама логіка входу в систему.
Ми не вважали головну сторінку обов'язковою точкою входу.
Людина може шукати конкретний товар, страву, доставку чи ресторан. Тому пошуковий трафік мав приводити її одразу у відповідну частину продукту.
Шукав товар, потрапляв у Gastro Market. Шукав доставку, потрапляв у Delivery. Шукав ресторан, потрапляв у Restaurant.
При цьому далі користувач лишався всередині однієї екосистеми.
Це дозволяло поєднати дві речі, що часто конфліктують між собою: глибоку спеціалізацію окремих розділів і цілісність одного продукту.
The digital ecosystem. У результаті LavShash мав виглядати не як набір пов'язаних між собою сайтів, а як єдина система. Цей розрив між «технічно вирішує» і «реально працює як діджиталізація» ми розбираємо у Автоматизація бізнес-процесів: що реально означає діджиталізація.
У користувача був один бренд і один загальний digital experience. Але всередині існували різні сценарії: Shop. Order. Visit.
І кожен з них мав власну інтерфейсну логіку.
Це було особливо важливо для мобільної частини. Delivery не мала відчуватись як мобільна версія ресторанного сайту. Тому для неї проєктувались окремі застосунки iOS і Android.
