Однажды я написал, что у нас бюро гуманистического дизайна. Эта конструкция пришла мне на ум как-то случайно, когда я хотел подчеркнуть особенность нашего подхода.

О чем это?

Гуманистический дизайн — это про дизайн с любовью к человеку. В первую очередь — к человеку, для которого мы и дизайним все эти приложения, сайты и прочие цифровые продукты. Как говорится, это — база. И эту базу принято называть человекоцентричностью (или, прости господи, человекоориентированностью). Я не стал называть наш подход человекоцентричным или человекоориентированным не только потому, что это тяжеловато звучит (да и читается не легче). Дело в том, что помимо конечного пользователя, в дизайн-проекте есть еще две категории людей, которые тоже нуждаются в любви: это представители заказчика и команда разработки. И в своем подходе мы стараемся залюбить (в наилучшем значении этого слова 😅) всех действующих лиц!

Как же мы можем это сделать?

Любовь к пользователю продукта мы несем непосредственно через дизайн.

Например, когда мы делали приложение SmartBoats — для аренды прогулочных катеров в Питере, мы постарались максимально делегировать весь «головняк», с которым пользователь может столкнуться при оформлении заказа, приложению.

Так, мы изначально выстроили два параллельных сценария бронирования. Если вам важно выбрать для прогулки «катер мечты» — и вы готовы подстроиться под даты, когда такой катер будет доступен — есть первый сценарий. Если же подстраиваться вы не готовы, можно воспользоваться вторым. Он как раз рассчитан на то, что прогулка нужна вам конкретно сегодня вечером или в следующие выходные — выбирайте дату и приложение предложит гарантированное доступные варианты.

Как делать не надо?

Все это звучит вполне логично, но довольно часто в приложениях ограничиваются одним сценарием. Как это могло бы выглядеть в случае с нашим приложением? Мы могли бы просто показывать пользователю витрину со всеми доступными катерами. И тогда мы обрекли бы на муки всех тех людей, кому прогулка нужна была бы на конкретную дату.

Скажем, вы приехали в Питер всего на пару дней — и вам очень захотелось прогуляться по Неве. Вы открываете приложение, видите каталог катеров, выбираете первый понравившийся… Но он оказывается недоступен в эти дни! Возвращаетесь в каталог, выбираете другой катер, иии… Тоже недоступен! Если вам «повезло» оказаться городе еще и в праздничные дни — шариться по каталогу вы могли бы еще очень долго. 🫠

В лучшем случае, вы бы проявили железную настойчивость и смогли-таки найти свободное судно на нужное время. Но чего скрывать: осадочек бы у вас уже остался — и он был бы не в пользу репутации прокатного сервиса. В худшем — вы бы просто решили, что не так уж вам и нужна эта прогулка. А это значит, что бизнес бы не досчитался тех самых денег, которые вы пять минут назад были рады ему занести.

А как же кнопочки?

Как видно, настоящая любовь к пользователю проявляется в такой вот проработке сценариев, а не в красоте кнопочек. Точнее сказать, красивые кнопки, карточки и вот это вот все — конечно, тоже про любовь (к пользователю, к прекрасному), но далеко не в первую очередь. В конце концов, дались вам эти чудесные кнопки, если ваша задача не решается или решается дорогой страданий? 🤔

Если вернуться к примеру с приложением аренды катеров, то о красоте мы, конечно, тоже не забыли. Помимо того, что мы выстроили целую дизайн-систему на основе имевшегося у заказчика фирменного стиля (адаптированную именно под специфику мобильного приложения), мы дико упоролись по теме разных типов судов. Так, мы изучили все основные виды катеров, яхт и теплоходов, чтобы отрисовать под каждый вид уникальный маркер для карты и иконку для каталога. 🤪 Вообще про кейс этого приложения я обязательно расскажу подробнее, и не раз. Но потом!

Как оказалось, мне слишком много есть чего сказать на тему гуманистического дизайна — поэтому то, что планировалось как один пост, я вынужден разбить на несколько! В следующем посте поговорим о том, почему любовь к заказчику во много выражается степенью нашей любви к пользователю 👀