- Все статьи цикла:
- Дизайн данных (часть 1). Что и зачем? (вы здесь)
- Дизайн данных (часть 2). Как?
- Дизайн данных (часть 3). Меняемся?
- Дизайн данных (часть 4). Матчасть: основы.
- Дизайн данных (часть 5). Матчасть: базы данных.
- Дизайн данных (часть 6). Матчасть: API.
- Дизайн данных (часть 7). Прототипирование.
Этим коротким постом я запускаю целый цикл статей, посвященных одной из самых туманных и не по праву обделенных вниманием областей проектирования — дизайну данных.
Упомянутый цикл в большей степени рассчитан на дизайнеров (настоящих) и проектировщиков (всяких), но может оказаться полезен и кодерам (начинающим и миддлам) — если любые из этих ребят хотят стать полноценными продуктовыми дизайнерами.
В связи с серьезностью темы, сразу же хочу расставить пару точек.
Пара точек
Во-первых, речь пойдет вовсе не о визуальном представлении информации aka инфографика. Это скучно, об этом написано уже множество материалов. Я лучше расскажу о том, как и зачем настоящий дизайнер должен иногда окунаться в один из котлов технического проектирования. А для этого давайте сперва разберемся с терминологией. В частности, с дизайном. Ведь дизайн — это не только про визуальную часть продукта. Это куда более широкая область, чем кнопочки и картинки. И визуальное представление информации, и дизайн данных — лишь срезы главного, общего дизайна продукта. Но срезы эти совершенно разные.
Во-вторых, дизайн данных — это не информационное проектирование. Последнее — про структуру подачи информации, про процесс ее организации в удобную для пользователя (и компании) форму. Тоже интересная тема, но и она уже неоднократно освещалась — в частности, прекрасным специалистом Ларой Симоновой.
Ну и в третьих, все нижеизложенное в значительной степени является лишь моим мнением, пусть и подтвержденным некоторым опытом. Врубайте на полную своё критическое мышление и го холиварить в комменты. В споре много чего рождается.
Итак?..
Итак, что же такое data design? Все просто. Это проектирование структуры, обмена и обработки данных. Это планирование того, где и как будут храниться данные в вашем продукте, как они будут передаваться между компонентами и как обрабатываться на каждом из них. Какую информацию нужно гнать на сервер, какая прекрасно полежит на клиенте (в приложении или браузере), а какой место только на сторонних сервисах. Более того, на клиенте, например, она тоже может лежать по-разному. Информация, в смысле. Данные.
Чушь какая-то, да? Нафига это все дизайнеру? Мы ж про UX, вроде. Ну максимум — про компоненты и технические ограничения. Какие данные? А программисты тогда зачем?
А затем, что программисты — это последний рубеж. Это, если угодно, строители вашего проекта. Высококвалифицированные, в экзоскелетах и с высокоточными лопатами, но — строители. Пусть даже инженеры, но всегда — довольно узкоспециализированные. Если вам повезло иметь на проекте выделенного программного архитектора, это прекрасно. Еще лучше, если он может работать с вами в связке — и буквально по шагам проходить за вами весь проект. Но так будет не всегда. Чаще всего «архитектор» — именно вы. И если вы плохо справитесь, то программисты будут обливаться кровавым потом, силясь выстроить безопасную, масштабируемую, стабильную и, главное, работающую по вашим «чертежам» систему.
На пальцах
К примеру, есть у вас мобильное приложение. Пусть у него будет сервер (middleware), на котором хранятся картинки разные. Например, аватарки. Пользователь просматривает пользователей, лайкает кого-то, каких-то добавляет в избранное. А теперь, внимание, вопрос: скорость загрузки этих самых аватарок влияет на качество пользовательского опыта? А увеличение количества пользователей, тоннами качающих с сервера картинки, влияет на скорость загрузки этих самых картинок? Да и да, разумеется. Картинки должны грузиться как можно быстрее (а уже просмотренные — так вообще моментально). Ширина канала сервера, как правило, не резиновая — и чем больше изображений качается с сервера единовременно, тем меньше остается скорости для остальных.
Что нас спасает? Правильно, кэширование. А что делать, если пользователь изменил свой аватар, но прежний у кого-то еще валяется в кэше? В какой момент и как нужно провести обновление устаревшей картинки? Вы уверены, что разработчики вообще подумают об этом? А даже подумав, не сделают это топорно, прямо на глазах у пользователя меняя одно изображение на другое? Вроде, банальность, но встречается повсеместно.
Или вот еще пример: стандартный сайт интернет-магазина. Пользователь, уже зарегистрированный в системе, но не авторизованный, накидывает себе в корзину товаров. Чтобы не захламлять базу данных, для неавторизованных покупателей сохранение содержимого корзины реализовано через куки. И вот наш пользователь набрал десяток товаров и вдруг вспоминает, что может оплатить часть суммы бонусными баллами. Он спокойно нажимает кнопку «войти», вводит логин/пароль и — оп! — содержимое его корзины пропадает! Сорок минут придирчивого сравнения, полсотни изученных страниц — все впустую. А произошло это лишь потому, что для вошедших в свой аккаунт пользователей корзина работает уже с БД. Разумеется, перенос данных из кук, объединение корзин никто не спроектировал.
Копнем чуть глубже. Допустим, дизайнер это учел и сказал программистам: объединяем корзины. И даже, возможно, указал, какая из них приоритетна в случае совпадения позиций. Но проект развивается — и данные, которые сохраняются для этих двух типов корзин, могут со временем начать различаться. Усложняется поддержка кода, сыпятся баги, посетители тратят нервы и пулей вылетают через верх воронки конверсии. Тут уже проблема в плохой структуре данных, в ее слабой унификации.
Так-так…
Если после описанного кто-то скажет, что дизайн данных (как и техническое проектирование в целом) не влияет на UX — он может даже не переходить по ссылкам ниже. Остальных же приглашаю погрузиться в сюрреалистический (поначалу) мир дизайна данных.
- Все статьи цикла:
- Дизайн данных (часть 1). Что и зачем? (вы здесь)
- Дизайн данных (часть 2). Как?
- Дизайн данных (часть 3). Меняемся?
- Дизайн данных (часть 4). Матчасть: основы.
- Дизайн данных (часть 5). Матчасть: базы данных.
- Дизайн данных (часть 6). Матчасть: API.
- Дизайн данных (часть 7). Прототипирование.
