страница 4 из 5
Задача этой статьи — дать базис, ввести в терминологию матчасти data design. Чтобы потом каждый из вас мог посоветоваться с техническими специалистами, не испытывая при этом «эффекта вавилонской башни». А то и вообще самостоятельно прогуглить «белое пятно» знаний о проекте.
Третий пост, посвященный дизайну данных. Что такое API, как и зачем проектировать обмен данными между компонентами системы.
Вторая статья цикла про дизайн данных. О том, как вообще происходит работа над дизайном данных, что при этом надо учитывать и какие знания понадобятся.
Этим коротким постом я запускаю целый цикл статей, посвященных одной из самых туманных и не по праву обделенных вниманием областей проектирования — дизайну данных.
Мы все знаем, что такое бесшовный опыт. Мы даже проектируем контекстное переключение между сервисами/приложениями/устройствами — и тратим порой на это довольно много времени. Так почему же бесшовное взаимодействие поддерживают лишь считанные единицы даже самых крутых наших продуктов? Ответ не так прост, как может показаться.
На территории стран бывшего Союза есть извечный, казалось, вопрос: дизайн — это про что? Про продукт в целом или только про его UI, внешнее проявление? И как к дизайну относится проектирование? А может, это вообще одно и то же? Давайте разбираться.
Любое перепроектирование предполагает меньше неопределенности — а значит, оно безопаснее, проще. Но почему-то многие берутся за него со старым подходом: обычным, привычным и унылым. А там же нюансов — миллион. Не учтешь какие-то, и работать придется больше, а результат будет не таким стабильным.
Все мы фэйлимся. Но даже самые матёрые из нас, набравшись храбрости, вещают со сцен полубесполезные истории о том, как они слажали — и сразу все исправили. И стало даже лучше, чем было. Это вредно. Это создает вокруг ошибок ореол несерьезности, некой «возвратности», когда все можно поправить. Как так получается и почему каждый должен вспомнить хотя бы один свой «окончательный» фэйл — и поведать о нем миру.
Задачи технического дизайна программных продуктов: границы, риски, возможности интерфейса, оптимизация работ. Почему проектировщики и продуктовые дизайнеры должны хотя бы на базовом уровне знать матчасть. Почему неприемлем подход «кодеры разберутся» и какую цену заплатит бизнес, если вы считаете иначе.
Небольшая заметка-памятка тем дизайнерам и арт-директорам, которые решили создать для своей компании дизайн-систему. Не претендую на непреложность нижеизложенного, ибо пишу во славу смысла здравого, а не хайпа ради.