Модель данных в интерфейсе
И как она определяет вид ваших экранов
Здравствуйте, друзья!
Наверняка, вы не раз рисовали какие-то экраны для разных приложений (либо открывали Sketch, создавали артборт и пустота вглядывалась в вас). Каждый ваш экран состоит из разных контролов и контента, которые следуют какой-то логике, которую вам в виде грубого прототипа (мокапа) передал продакт менеджер. Вы рисуете кнопаньки, формочки, чекбоксики, вставляете имиджи и вроде бы так все и должно быть правильно…
Но, наверняка, вы в какой-то момент задумались: «А почему все именно так? А не так-то и так-то?». Можно пойти поспорить с продакт менеджером или продакт оунером, который скажет вам, что все эти мокапы они родили на базе ресерча и юзер стори и, мол, иди лесом, не спорь со старшими. Или наоборот, примут ваши доводы и все переделают. Не так важно на самом деле, я немного про другое.
А из чего на самом деле состоит экран, который вы с такой любовью рисуете? Что скрывается под маской мимимишности?
Модель данных
Любой разработчик сразу понял, о чем идет речь. Рады за них 👌🏻
А мы, дизайнеры, что под этим понимаем? На самом деле тоже самое, только не осознаем этого. А модель данных влияет на дизайн не то, что напрямую, а вообще определяет всё, что располагается на экране смартфона!
Все элементы на экране являются данными. Весь экран обязан своему существованию данным: Title в нав баре, аватарка, имя и фамилия пользователя, его статус (залогинен или нет), состав настроек приложения, вид ленты событий (название, подзаголовок, время и дата публикации, картинка, количество лайков, названия кнопок) — все это данные, которые лежат в понятном древовидном виде где-то в недрах кода либо на удаленном сервере, в бэкенде так сказать.
Откуда появляется модель данных?
Вопрос, ответ на который может изменить сроки, стоимость и качество проекта в целом.
- Если эта модель данных придумывается разработчиком на базе документации, ваших скринов и чьих-то еще домыслов, то у меня для вас не вот чтобы супер новость. Разработчик сделает по-своему, не беря во внимание дальнейшее расширение функционала (потому что может и потому что никто ему модель данных не дал). Итог — модель придется переделать потом, а потом ее синхронизировать с дизайном. Такое себе упражнение.
- Продакт менеджер, составляя документацию, в теории, должен описывать модель данных. И в больших компаниях так и есть. А в маленькой компании или стартапе с вероятностью 90% до модели данных его руки никогда не дойдут.
- Это сделает UX/UI дизайнер, то есть вы.
Забавно то, что ваш дизайн экранов на самом деле содержит модель данных. Просто вы никогда об этом не задумывались и не знали куда смотреть 😱.
А что делать-то?
Можно делать как и раньше — брать ТЗ или мокапы и по ним рисовать красоту.
А можно по-другому. Вы садитесь и начинаете с самого верха описывать модель данных.
Пример
Возьмем веб-камеру, к которой вы можете дистанционно подключиться через приложение, чтобы лицезреть как любимый кот обдерает не менее любимые обои.
Давайте быстренько опишем то, что мы знаем о камере:
- Есть дом — Home. Он не один (на даче ведь тоже камера не помешает, правда ведь?), поэтому мы даем ему имя (Label) и ID (уникальный номер, позволяющий его отлечить от другого дома).
- Внутри дома есть комнаты — Room. И чтобы знать какая камера в какой комнате установлена, нам нужно как-то описать эту комнату. У комнаты есть ID и набор других свойств: имя и украшательства (Фото / Цвет / Иконка). И у нее есть статус — в сети ли наши камеры в этой комнате или вырубило пробки и именно в этой комнате. А комната может быть и гаражом или студией. Мы не знаем как пользователь настроит, но тем не менее, эта абстрактная сущность Room (Комната) в любом случае останется. Если камера одна, то все равно у нас будетследующая вложенность: Home -> Room -> Camera.
- Камера — Camera. Камера тоже имеет ID, имя, украшательства. А еще у нее бывают разные статусы. Например, On / Off / Error (ошибка) / Фиксация движения / Режим ожидания / Ночной режим. И статус батареи! О да, вдруг производитель оснастил ее аккумулятором на случай падения напряжения! Тогда у нас появляется статус батареи (Battery status): 100–10% заряда / Осталось 10% / Осталось менее 5% и скоро вырубится.
- Вы также можете описать пользовательскую модель, если у вас есть регистрация 🙃.
Разумеется, продукты бывают разные и, как следствие, вместе с размером приложения растет и модель данных.
А ларчик просто открывался
Самые внимательные догадались, что сверху выписано достаточное количество информации, чтобы нарисовать экраны настройки дома, комнаты и устройства, включая все возможные состояния экранов!
Прикольно, да =))
Эта модель данных есть ни что иное, как логическое мышление, которое описывает работу устройства и приложения.
Главное помнить, что начинать строить модель данных надо ВСЕГДА с самой верхней абстракции. В нашем случае это был дом (Home).
Если бы мы начали с камеры и писали юзер стори, то могли бы забыть про дом (или вспомнить на этапе разработки, что очень дорого).
Вывод
Прежде чем что-то рисовать, надо понять какие данные лежат в основе приложения. На примере выше мы поняли, из каких кубиков будут состоять экраны камеры, комнаты и дома. Если модель проработать глубже, то можно раскурить многопользовательский режим — как люди будут одновременно работать с камерой, кто что может / не может делать, как приглашать пользователей и где и как их удалять.
В итоге у нас будет охренительная подсказка (листочек А4 с древовидным списком) для каждого экрана, которую мы сделали сами за пару часов. Она же застрахует нас фантазий и несуществующих кейсов.
А потом вы эту модельку вместе с дизайном спокойно передадите разработчикам, которые расцелуют вас дёсны – вы ведь с них сняли огромный пласт работы! =))
Всем бобра! ❤️
