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