Технический дизайн 5-6 минут на прочтение

Дизайн данных (часть 1). Что и зачем?

Поделиться:

Этим коротким постом я запускаю целый цикл статей, посвященных одной из самых туманных и не по праву обделенных вниманием областей проектирования — дизайну данных.

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

В связи с серьезностью темы, сразу же хочу расставить пару точек.

Пара точек

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

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

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

Итак?..

Итак, что же такое data design? Все просто. Это проектирование структуры, обмена и обработки данных. Это планирование того, где и как будут храниться данные в вашем продукте, как они будут передаваться между компонентами и как обрабатываться на каждом из них. Какую информацию нужно гнать на сервер, какая прекрасно полежит на клиенте (в приложении или браузере), а какой место только на сторонних сервисах. Более того, на клиенте, например, она тоже может лежать по-разному. Информация, в смысле. Данные.

Чушь какая-то, да? Нафига это все дизайнеру? Мы ж про UX, вроде. Ну максимум — про компоненты и технические ограничения. Какие данные? А программисты тогда зачем?

А затем, что программисты — это последний рубеж. Это, если угодно, строители вашего проекта. Высококвалифицированные, в экзоскелетах и с высокоточными лопатами, но — строители. Пусть даже инженеры, но всегда — довольно узкоспециализированные. Если вам повезло иметь на проекте выделенного программного архитектора, это прекрасно. Еще лучше, если он может работать с вами в связке — и буквально по шагам проходить за вами весь проект. Но так будет не всегда. Чаще всего «архитектор» — именно вы. И если вы плохо справитесь, то программисты будут обливаться кровавым потом, силясь выстроить безопасную, масштабируемую, стабильную и, главное, работающую по вашим «чертежам» систему.

На пальцах

К примеру, есть у вас мобильное приложение. Пусть у него будет сервер (middleware), на котором хранятся картинки разные. Например, аватарки. Пользователь просматривает пользователей, лайкает кого-то, каких-то добавляет в избранное. А теперь, внимание, вопрос: скорость загрузки этих самых аватарок влияет на качество пользовательского опыта? А увеличение количества пользователей, тоннами качающих с сервера картинки, влияет на скорость загрузки этих самых картинок? Да и да, разумеется. Картинки должны грузиться как можно быстрее (а уже просмотренные — так вообще моментально). Ширина канала сервера, как правило, не резиновая — и чем больше изображений качается с сервера единовременно, тем меньше остается скорости для остальных.

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

Или вот еще пример: стандартный сайт интернет-магазина. Пользователь, уже зарегистрированный в системе, но не авторизованный, накидывает себе в корзину товаров. Чтобы не захламлять базу данных, для неавторизованных покупателей сохранение содержимого корзины реализовано через куки. И вот наш пользователь набрал десяток товаров и вдруг вспоминает, что может оплатить часть суммы бонусными баллами. Он спокойно нажимает кнопку «войти», вводит логин/пароль и — оп! — содержимое его корзины пропадает! Сорок минут придирчивого сравнения, полсотни изученных страниц — все впустую. А произошло это лишь потому, что для вошедших в свой аккаунт пользователей корзина работает уже с БД. Разумеется, перенос данных из кук, объединение корзин никто не спроектировал.

Копнем чуть глубже. Допустим, дизайнер это учел и сказал программистам: объединяем корзины. И даже, возможно, указал, какая из них приоритетна в случае совпадения позиций. Но проект развивается — и данные, которые сохраняются для этих двух типов корзин, могут со временем начать различаться. Усложняется поддержка кода, сыпятся баги, посетители тратят нервы и пулей вылетают через верх воронки конверсии. Тут уже проблема в плохой структуре данных, в ее слабой унификации.

Так-так…

Если после описанного кто-то скажет, что дизайн данных (как и техническое проектирование в целом) не влияет на UX — он может даже не переходить по ссылкам ниже. Остальных же приглашаю погрузиться в сюрреалистический (поначалу) мир дизайна данных.

Следующие посты цикла

5/5 (26 голосов)
, Ваша оценка:

Комментарии (0)

Добавить комментарий

Чтобы оставить комментарий, войдите:
Нет соединения с сервером.Сервер получил неверные данные, попробуйте еще раз.

Похожие посты

Top